Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
> > Sylvain Wallez wrote:
> >
> > Hi cocooners,
> >
> > Now that we've got two branches for C2, what's the easiest way to
> commit
> > changes on both ? I made two checkouts (HEAD and cocoon_20_branch) :
> do
> > I have to manually copy modified files from one checkout to the other
> > and issue 2 commits, or is there a way to commit on both branches at
> > once ?
> >
> I think the only working solution is to make two commits. This is some
> overhead we have to cope with but I think it's unavoidable.
>
> My question is: Should we keep both branches in sync until we release
> the 2.0 final? I think we should, so I would suggest to really make
> always two submits.
> What do you all think?
I don't see it as a necessity that the HEAD branch have to be in sync after each
commit to the 2.0 branch. But I think we should use the CVS to sync it for us if
we need it and not commiting stuff here and there. So, lets see how CVS can help
us synching the branches.
1. Lets commit stuff needed for beta 2 to the 2.0 branch only.
2. Lets commit new/experimental stuff to the HEAD branch only.
3. Lets suppose that all that has been/will be commited to the 2.0 branch will
make its way into the HEAD branch someday.
4. If someone wants/needs to sync the HEAD branch with the 2.0 branch the
following procedure should be applied (the names in the brackets denotes
the local branch directory you need to be cd'ed]:
#make the changes available in the 2.0 branch (if needed)
[20_branch] cvs ci -m "..."
#make your HEAD branch up to date (if needed)
[HEAD] cvs upd
#join the HEAD with the 2.0 branch from the last merge point(*).
[HEAD] cvs upd -j cocoon_20_branch_mergepoint -j cocoon_20_branch
#cleanup merge conflicts (yes, this can be the hard work)
[HEAD] edit ...
#commit the joined version to the HEAD branch
[HEAD] cvs ci -m "..."
#move the cocoon_20_branch_mergepoint tag to the head of the 2.0 branch
[20_branch] cvs tag -d cocoon_20_branch_mergepoint
[20_branch] cvs tag cocoon_20_branch_mergepoint
(*)The first time we do that there is no mergepoint tag, so the '-j mergepoint'
must not be written.
There are some drawback to this procedure.
1. Lots of merge conflict will happen because of keyword expansion we use
in the source files ($Revision 1.2.1.$ etc.). Using the -kk options
on the join command can corrupt binary files if my understanding
of that option is correct.
2. The log comments entered on branch commits are not joined into the HEAD
branch.
Any comments?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
