Branch Management for VULab

[Ray Davis]

I know of two approaches to this problem. The standardly recommended 
one, along the lines of Colin's suggestion, is to use a Subversion 
vendor drop:

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

This seems to work for most normally sized projects. (When we tried it 
locally for customizing Sakai, we had to make many changes to the 
out-of-the-box Perl script supplied with Subversion, and then still had 
so many problems that we ended up ditching the approach entirely and 
begging our way into the central Sakai repository. But most of our 
difficulties were caused by Sakai's enormous bulk, and hearsay indicates 
that some of the others were fixed in later releases of Subversion.)

Another approach, perhaps most suitable when you're working against very 
large projects or with uncopiable source, is to rig up an "overlay" 
build that copies or patches your own code over the standard 
distributions. You'd then just tag your overlay code to match the 
releases of the vendor code.

Best,
Ray

>> *From: *"David Makalsky" <dmakalsky at gmail.com 
>> <mailto:dmakalsky at gmail.com>>
>> *Date: *May 7, 2008 4:57:23 PM GMT-04:00
>> *To: *fluid-work <fluid-work at fluidproject.org 
>> <mailto:fluid-work at fluidproject.org>>
>> *Subject: **Branch Management for VULab*
>>
>> Hi,
>>
>> The VULab team is looking to setup more rigorous branch management in 
>> the fluid SVN repository.  We are facing an interesting challenge, 
>> since our code is a modified version of a current open source 
>> application, namely PHPESP 
>> (http://butterfat.net/wiki/Projects/phpESP/).  Since there is no 
>> plugin architecture or any form of structured modularity, we are going 
>> right into the core code and making changes.  Colin suggested creating 
>> a branch with the original PHPESP code and add our code to trunk.  
>> This would allow for easy diff-ing and give some idea of which part of 
>> the code is modified and which isn't.
>>    
>> I would appreciate some input from the rest of the VULab community on 
>> this issue.
>>
>> Regards,
>> -- 
>> David Makalsky