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.
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.
>
> 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.
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.
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.
>
> There's a reason that management systems and practices are developed
> and
> rarely do they focus on simpler or faster.
You speak of 'management systems and practices' as if that were some
monolithic thing. This is a vast oversimplification of a complex topic.
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 
(text/plain)
