You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Carmen Sarlo <ne...@gmail.com> on 2009/02/16 23:24:04 UTC

Best practices to maintain code releases to production?

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

Re: Best practices to maintain code releases to production?

Posted by Ian Boston <ie...@tfd.co.uk>.
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 <ne...@gmail.com>:
>> 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
>>


Re: Best practices to maintain code releases to production?

Posted by Vincent Siveton <vi...@gmail.com>.
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 <ne...@gmail.com>:
> 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
>