Branch Management for VULab

[Aaron Zeckoski]

The overlay procedure is what we use at Cambridge (along with a
smattering of patches). We have a local copy of the vendor code. When
building the system we checkout the local copy and then checkout the
overlay (which is basically identical code structure but only the
files we have changed). Then the overlay is written on top of the
local vendor code and you build. This can sometimes be easier to
manage but it is quite easy to get out of sync if there are large
changes to the vendor code (especially structural).

-AZ


On Thu, May 8, 2008 at 5:09 PM, Ray Davis <ray at media.berkeley.edu> wrote:
> 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
>
>
> _______________________________________________
>  fluid-work mailing list
>  fluid-work at fluidproject.org
>  http://fluidproject.org/mailman/listinfo/fluid-work
>



-- 
Aaron Zeckoski (aaronz at vt.edu)
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]