for instance, i just modified the file BUILDING.txt in the HEAD of jboss-mail.
so i guess i would do the following (which i'll do on the command-line as i write):
[note: i realized after doing this that in general, we'll usually want to merge from
M1 to HEAD instead, since i guess no new features will go in M1 yet the HEAD should
get the bugfixes... sorry... steps 7+ should handle this case]
1. do a cvs commit as usual to get the change into HEAD. tag with something like
'merged-to-M1-1' to indicate that everything from the branch point to HEAD has been
(will be in steps 2-5) merged into the branch from HEAD for the first ('-1') time. we
may use this tag in later merges from HEAD to branch to avoid conflicts (using two
'cvs -j' options).
2. in the branch (separate checkout), do a 'cvs update -j HEAD BUILDING.txt' (since i
know i only modified BUILDING.txt, otherwise i'd omit that filename). this will merge
the change in HEAD since the branch point into the branch.
3. in the branch, check for conflicts and if so correct them (shouldn't be any if
developers don't conflict)
4. commit the change to the branch (the big boy/gal step)
5. tag the branch with a tag like 'merge-from-head-1' to help keep track of things.
6. we're done. further steps are how one might proceed later on, with an important
difference: how to avoid re-merging changes and the resulting conflicts
7. now, for instance, lets say we instead do a bugfix on the branch and go through the
analogous procedure of committing, tagging, merging to HEAD, etc. in general, this
will involve the whole repository and not just a single file like 'BUILDING.txt'.
8. so after doing the same procedure as before, we'll have a tag on the branch called
something like 'merged-to-head-1' from step 7.
9. now we want to commit the second bugfix on the branch and merge it into the HEAD
too. we commit and tag the fix on the branch as 'merged-to-head-2'.
10. now we do a merge of all the changes between tags 'merged-to-head-1' and
'merged-to-head-2' to the HEAD, thus picking up only the second bugfix. thus, in the
HEAD repository, we execute a 'cvs update -j merged-to-head-1 -j merged-to-head-2'
11. this avoids re-merging the first bugfix after the branch point and the inevitable
conflicts it would cause.
so basically its pretty standard stuff and folks probably already know all this. i
picked it up myself from the book 'open source development with cvs, by karl fogel'
(any errors here are mine). what i mainly wanted to accomplish was to informally get
some kind of consensus and awareness of the coordination between developers that helps
to avoid conflicts when branches are being used. the apparent answer is a common
naming scheme for tags at most control points, to communicate what's been merged into
what, where, when and how. don't worry --- when we move onto M2 we can then delete all
those verbose tags from the repository to clean things up.
somebody probably knows a better way to do this than i do, and so i'd greatly
appreciate getting educated if someone could provide some more information or
references here.
one pitfall (of many?) in this procedure may be due to a deficiency of cvs itself,
which is that if another developer is doing the same thing while you're in the middle
of steps 2-5, you'll cause each other problems. that's because cvs doesn't use
transactions and furthermore doesn't provide atomicity. but chances of this happening
are quite small.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831494#3831494
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831494
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
