Yes, It can be a bit of a nightmare to manage on a big project with
lots of code, fortunately Shindig is not the 1.8M lines of code that
Sakai is, Vincent I know your pain if you've been vendor dropping
Sakai... sorry.
If you are using svn,
Do a vendor drop of a release branch,
then branch that vendor drop to make your modifications as vincent says.
I would recommend that you continue making vendor drops of the release
branch at regular intervals so you have a sequence of snapshots of the
release branch.
You then have a vendor drop history that you can merge into your local
branch.
If you are using git, which I would recommend (hg also)
Just track the release branch and have your own branch.
rebase the release branch which will pull *all* the commits on the
release branch
and merge/cherry pick/what ever takes you fancy
There is a Git mirror of Shindig trunk out there
http://jukka.zitting.name/git/?p=shindig.git
Th experience of the sakai community who tend to take 1 release per
year has that its been hard work with svn vendor drops and needs a
snapshot about once a week to make the drop history mergable.
Those using Git have had no problem,
Many of the SVN users have just moved all their code base into the
same svn repo as the release... not an option for Shindig.
HTH
Ian
(I think a later version of SVN might do cross repo branch merges but
I haven't tried)
On 16 Feb 2009, at 22:33, Vincent Siveton wrote:
Hi Carmen,
I already had this problem for the Sakai project in the past (hi
Ian :) )
What we did:
- import the current HEAD or the release
- create a branch
- make modifications in this branch
- update the tree and merge/rebranch
The main problem is about versionning: I recommend you to create your
own version.
HTH
Cheers,
Vincent
2009/2/16 Carmen Sarlo <[email protected]>:
What do you recommend for deploying shindig code into production?
When to
cut-off updated code? We are using the java version of shindig. We
would
also like to maintain our shindig releases in our maven repo.
Thanks,
Carmen
