Now really, that's a self-serving assertion if ever I've read one. I don't think I've 'resorted' to anything. My company has a process that works quite well for us, and I shared it. You're free to disagree, and I welcome the discussion, but your choice of words is unhelpful.
On Mar 11, 2010, at 8:04 PM, Craig White wrote:
On Thu, 2010-03-11 at 19:53 -0600, Alex Dean wrote:
On Mar 11, 2010, at 4:08 PM, Craig White wrote:----
On Thu, 2010-03-11 at 14:47 -0700, Eric Cope wrote:
It needs to be deployed to Linux and Windows. I can't just tar /dir----
because I have .svn files I don't want to include as well as test
directories. I planned on using a form of tar/zip.
ignoring that this really should have been on the development mail
list...
svn help export
I can't imagine a single good reason for using an existing directory
instead of exporting specific 'tags' from svn and using that for
packaging except that there really wasn't much understanding and
planning in svn.
Can't speak for anyone else, but at least in my case I think there was
quite a lot of understanding and planning.
If the build machine already has a recent working copy of the branch
you want to build, switching to a different branch or getting the last
bug fix with 'svn up' or 'svn switch' is a lot simpler and faster than
getting another full 'svn export'.
I tend to think bigger picture and don't resort to simplifications just
because they are simpler or faster.
You can do that with just a revision number. You don't need a tag. If you like to use tags, that's of course fine, but all the points you make are satisfied just by knowing a branch and revision number.
Reasons that come immediately to my mind to only use an svn export (from
a specific 'tag':
- stability - you can always see what was packaged by doing a checkout
in another directory or on another computer.
Don't misunderstand. The working copies we do builds from have no local modifications. I'm not talking about a developer doing a build on his local machine from a working copy which is also used for development. That's not the case. I'm talking about machines which are dedicated to doing nothing but builds, and have working copies of release branches. But if you just built r10198, and some last-minute bugs were found and fixed in r10199, it's much faster (and no less accurate or repeatable) to 'svn up' rather than doing another 'svn export'.
This is a common pattern for integrating cruisecontrol.rb with subversion. You keep a local working copy on the test machine. Nobody makes modifications to it, it's just a local cache of the software under test. Every time a new revision is detected, CC runs 'svn up' and re-runs all the unit tests. You get results fast, and developers know quickly if something they've done has broken a test.You speak of 'management systems and practices' as if that were some monolithic thing. This is a vast oversimplification of a complex topic.
There's a reason that management systems and practices are developed and
rarely do they focus on simpler or faster.
Further, emphasizing process simplicity and speed (while maintaining repeatability, of course) is quite legitimate. Complex and unnecessarily time-consuming processes are those which encourage mistakes and increase expenses. The whole agile approach to software is about making the process simpler and faster, while improving quality and value.
alex
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss