RE: Problem: Merging Trunk and Branch several times
Hi, In our company we have very similar requirements. Following advice from this mailing list, here's what we do: 1. Updates from trunk to branch For each branch keep a moving tag on the trunk which points to where you last updated from the trunk to that branch. Let's call it last_branchXXX_update. Initially this tag = start point of your branch. Your branch update procedure should be: - update (-j last_branchXXX_update -j HEAD) - solve conflicts - commit to branch - move tag on trunk to HEAD 2. Updates from branch to trunk The important point here is the requirement that the branch will be fully updated with the trunk first (last_branchXXX_update = HEAD). While the branch update is being done, changes may be committed to the trunk, so you might need to repeat the update procedure a few times. When the branch is fully updated with the trunk, you don't need another update, with possible conflicts, etc. - All you want is that the trunk's content will be exactly as the branch. Quoting Greg A. Woods, you need to: 1) Check out a working directory on the branch. 2) Check out a working directory on the trunk. 3) Copy all the project files (i.e. not the CVS/* files!) from the working directory created in step #1 to the working directory created in step #2. 4) within the working directory created in step #2 cvs add any new files (show as '?' in cvs -nq update) and cvs remove any old files (have timestamps older than the copy in step #3) 5) cvs commit in the working directory created in step #2 You should write scripts to perform the two update operations (as well as for creating branches) - it's too error prone to be done manually. These scripts should also handle commit failures, etc. Yuval. -Original Message- From: Ralf Beckers [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 4:23 PM To: [EMAIL PROTECTED] Subject: Problem: Merging Trunk and Branch several times Ahoi, I have a little problem with understanding CVS ... We need to develop on the trunk, where all general improvements and bugfixes are done (not release specific bugfixes!). We also develop new features in new branches, till they are stable. Sometimes, it is neccessary to merge bugfixes from the trunk to the branch. Sometimes, there will be a merge from the branch to the trunk. To avoid conflicts, we use update with 2 times -j to get just the changes and not the merges (the own code back). Therefor we set 2 tags (premerge and merge), for better access. The poor thing is, that we won't get the conflict solutions, since the merged-tag will be set after the commit. (I've done a poor ascii-art for more details). --- time --- branch +-(A1)-(T2)--+(A5)-(T5)-(A6) | code changes *code changes ^ | plus conflict * /*\ - root-of-brnch -+* * | \*/ * | code changes Vcode changes * trunk +-(A2)-(T1)-(A3)-(T3)--(A4)-(T4)-+ T1 = cvs tag premerge-brnch_1 T2 = cvs tag branch-brnch_1 A1 = cvs commit A2 = cvs commit A3 = cvs update -j root-of-brnch -j branch-brnch_1 emacs to solve conflict. cvs commit T3 = cvs tag merged-brnch_1 A4 = cvs commit T4 = cvs tag trunk_bugfix_1 T5 = cvs tag premerge_bugfix_1 A5 = cvs commit A6 = cvs update -j root-of-brnch -j premerge-brnch_1 - conflict (again!)... now I got a conflict in the line, which causes the conflict before within the trunk-merge. Is it really neccessary to fix this conflict twice? How can I then ensure, that it will befixed the same way as in the trunk, and that the code is identical? Or do we use CVS the wrong way (how can this merges be used better)? Thanks in advance, Ralf Beckers ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Problems using CVS transparently
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sonam Chauhan Sent: Thursday, April 04, 2002 7:46 AM To: [EMAIL PROTECTED] Subject: Re: Problems using CVS transparently ... Basically I need CVS only for versioning capabilities. Before a major release, I'd like to do something like this (params are wrong - I have no idea) cvs -tag -recurse -tag_name Release Number 9 souce-controlled-dir I could then use CVS to restore the directory or even specific file to previous release checkpoints. ... -End of Original Message If that's all you need, is it really worth the trouble of integrating with CVS? Why not just tar all your files at each release point and keep it somewhere? Whenever you want you can extract a file, a directory or the whole tree, diff between releases, etc. (Personally I would rather use a good source control system and some other tool for deployment, but I guess that's not an option here). Yuval. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Merging changes between branches
Hi all, We want to employ branches as a relatively isolated development environment, so that a small team can share a branch for a specific feature (or task). The branch is typically used for a few weeks, and when ready is merged to the main trunk. This should be a classic use for a CVS branch, or so I thought. I also used a very similar methodology in my previous company with ClearCase as our CM tool, and it worked very well. However, according to the docs, it seems that using CVS branches for this purpose isn't that trivial, at least in one respect: It should be possible to perform an update to merge changes from the main trunk into a branch (or vice versa). In CVS this requires me to remember when the last update was, and update with two -j flags, which is a bit awkward. (In CC this was simpler. I guess the difference is that in CC you have a real version graph for each file, and when you merge between versions you add an edge to the graph, and you get a new common ancestor to be used in your next merge operation). We intend to write a set of scripts to make working with branches easier. These scripts should also create the appropriate tags, handle the extra book-keeping, handle locking, etc. Has anyone else tried to do this or something similar? Is there a better solution? Thanks, Yuval. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
There is a bigger issue for non-sane formats. Notably Word documents which can't be diffed but logically should be. The solution here is to shoot anyone who brings one near your project:-). Just a quick side note: MSWord includes a diff tool. And IIRC, ClearCase even uses it if you compare two versions of the same word file... Yuval. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
I never actually used it, and I don't have CC here (we use CVS...), but I saw it in CC 4.0, in NT 4.0. (In the file history list select a version and select compare with previous version or compare with another version). Note also that MSword itself has the Tools/Track Changes/Compare Documents Yuval. -Original Message- From: Daniels, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 3:14 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not Just a quick side note: MSWord includes a diff tool. And IIRC, ClearCase even uses it if you compare two versions of the same word file... Where do I find it? Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
