OT: Method of packaging software for shipment

[Alex Dean]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100312/d69ebcb6/attachment.pgp