Re: How to extract fine-grained snapshot history?
Date: Wed, 16 Jun 2004 13:03:57 -0400 From: Scott Moynes [EMAIL PROTECTED] Kynn Jones wrote: Therefore, my question is: 1. How to extract the times of all the commits to a project (including recursively all subprojects, of course). 2. How to associate each of these times with the branch that was active when the corresponding commit took place. I've used CVSps http://www.cobite.com/cvsps/ to some success for a similar problem. Though, from what I understand of your use case, you will probably have to wrap it up in some scripting glue. Very cool. Thanks for the tip! kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
How to extract fine-grained snapshot history?
For any given project under CVS control, every time someone makes a commit, the project changes state, as far as CVS is concerned. The finest-grain history of this project, as far as CVS knows it, would consist of a sequence of snapshots of the project as it would appear right after each one of these commits. To be more precise, suppose that after each commit, we did % cd $WORKING_DIRECTORY/.. % rm -rf $WORKING_DIRECTORY % cvs co [-r $ACTIVE_BRANCH] MyProject % tar czf MyProject_Snapshot_xxx.tgz MyProject where $ACTIVE_BRANCH is the branch that was current when the commit was issued (if it was the trunk, then the -r option to the checkout command is omitted). Then we would end up with a sequence of snapshots (in this case compressed tar files) of the project. The repository holds all the information necessary to recreate such a sequence of snapshots. If there were only one branch to worry about, getting this sequence would be simply a matter of extracting from the repository the times of all the commits to MyProject and for each of one these times doing a checkout of MyProject with the appropriate argument to the -D option. The problem is more complicated when the project has multiple branches, because it requires associating each commit time with a branch. Therefore, my question is: 1. How to extract the times of all the commits to a project (including recursively all subprojects, of course). 2. How to associate each of these times with the branch that was active when the corresponding commit took place. Thanks! kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to extract fine-grained snapshot history?
X-Original-To: [EMAIL PROTECTED] From: Jim.Hyslop [EMAIL PROTECTED] Date: Wed, 16 Jun 2004 09:18:18 -0400 Kynn Jones wrote: Therefore, my question is: 1. How to extract the times of all the commits to a project (including recursively all subprojects, of course). 2. How to associate each of these times with the branch that was active when the corresponding commit took place. I don't know if there's a simpler way, but my first reaction would be to write a loginfo script, which will capture the information you need. You'd have to do a little extra work to match the revision number against the branch. I'm not sure I follow you. It sounds to me like your solution is for recording the commit times and associated branches as I go along, so that, in the future, I could generate the snapshot sequence. But what I want to do is to generate the snapshot sequence *retroactively*, using the information about past commits stored in the current repository. My guess is that all the information is encoded somehow in the RCS files. (Although maybe other files under $CVSROOT/CVSROOT have essential, or at least useful, information for what I want to do?) The problem is to extract the data from the RCS files. For example, in one of such files I find the following: 1.3 date2004.06.10.19.32.06;author jones; state Exp; branches; next1.2; 1.2 date2004.06.09.14.06.20;author jones; state Exp; branches 1.2.4.1; next1.1; 1.1 date2004.06.09.14.06.18;author jones; state Exp; branches; next; 1.2.4.1 date2004.06.09.14.06.23;author jones; state Exp; branches; next; What do these dates mean? Are they commit dates? And does the revision following the branches keyword refer to the branch that was active at the time of the commit? I suppose it would be useful to read a detail description of the anatomy of an RCS file, and of any other $CVSROOT/CVSROOT file that may contain the time and branch information I need. kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
How to undo a change to a branch
I just mistakenly committed a change to a (non-trunk) branch. What's the best way to undo this change? (I'm tempted to just delete the change in the RCS file, but I figure I'd better learn the right way to do this.) Thanks! kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Any CVS tricks for creating patch files?
To create a patch, I could do this: % cvs co -d buggy -r Release_0_1 MyProj % cvs co -d fixed -r Release_0_1_Bugfixes MyProj % LC_ALL=C TZ=UTC0 diff -Naur buggy fixed Release_0_1_Patch ...but I wonder if there are some CVS tricks to streamline the process further. Thanks! kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any CVS tricks for creating patch files?
Date: Mon, 7 Jun 2004 18:08:20 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) [EMAIL PROTECTED] writes: ...but I wonder if there are some CVS tricks to streamline the process further. You mean like the cvs patch command? That'll probably do it. :-) kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
cvs checkout: move away foo; it is in the way
Sorry, I noticed a typo in the interaction transcript I posted in the original message for this thread (see comments beginning with ###). Date: Fri, 4 Jun 2004 18:17:03 -0400 (EDT) From: [EMAIL PROTECTED] Subject: cvs checkout: move away foo; it is in the way To: [EMAIL PROTECTED] OK, here's an interaction that illustrates yet another bizarre (to me) CVS conundrum (summary: I import some files, create a branch, modify one file on this branch, commit it, delete the CVS directory, and reimport): % export CVSROOT=/home/jones/cvs_test % rm -rf $CVSROOT % cvs init % mkdir Foo % cd Foo % touch foo % cvs im -m '' Foo vendor_1 v1 N Foo/foo No conflicts created by this import % cvs co -d . Foo cvs checkout: Updating . U foo % cvs ta -b branch_1 cvs tag: Tagging . T foo % cvs co -d . -r branch_1 Foo cvs checkout: Updating . ### In my original post, the following line was given as ### % date ### missing the redirection part. % date foo % cvs ci -m '' foo Checking in foo; /home/jones/cvs_test/Foo/foo,v -- foo new revision: 1.1.1.1.2.1; previous revision: 1.1.1.1 done % rm -rf CVS % cvs im -m '' Foo vendor_2 v2 U Foo/foo No conflicts created by this import % cvs co -d . -r vendor_2 Foo cvs checkout: Updating . cvs checkout: move away foo; it is in the way C foo Why am I getting the error message cvs checkout: move away foo; it is in the way? Can anyone make any sense of this? Thanks! kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
CVS bug? cvs checkout: move away bar; it is in the way
OK, I've significantly narrowed down the problem from my original post (which, I now realize, had much irrelevant stuff). I also provide a script below that reproduces the problem if anyone wants to play around with this. All you need to do to it is edit the value of TESTCVSROOT, and it's ready to go. I thought that my confusion had to do with my incomplete understanding of CVS, but now I think that what I'm seeing below is a bona fide CVS bug. SUMMARY: I import some files, and successfully check out the vendor branch; then I repeat the process, starting from scratch, and modifying one file before the import step; when I attempt to check out the vendor branch, as before, I get an error; I've added comments and blank lines, for clarity, to the transcript below. ### Initialize % TESTCVSROOT=/home/jones/cvs_test % rm -rf $TESTCVSROOT % cvs -d $TESTCVSROOT init % rm -rf Foo mkdir Foo cd Foo % echo -n 0 bar % cvs -d $TESTCVSROOT import -m '' Foo vendor_1 v1 N Foo/bar No conflicts created by this import % cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo cvs checkout: Updating . U bar ### Everything OK so far % cd .. ### Repeat the whole process, with a different ### bar file, and a different release tag during ### the import step % rm -rf Foo mkdir Foo cd Foo % echo -n 1 bar % cvs -d $TESTCVSROOT import -m '' Foo vendor_1 v2 U Foo/bar No conflicts created by this import % cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo cvs checkout: Updating . cvs checkout: move away bar; it is in the way C bar ### Not OK this time; bar has a conflict (???) ### Rename bar so that it is cvsignore'd, and ### attempt checkout again % mv bar bar.orig % cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo cvs checkout: Updating . U bar ### Everything OK this time ### What was the conflict all about? % diff bar bar.orig echo $? 0 None of this makes sense to me. I want to understand why it is that the second checkout fails, while the first one succeeds. Why is there a conflict in bar, when, as shown at the end, the version that was in the way is identical to the one that was ultimately checked out? Any clues would be much appreciated! Thanks! kynn P.S. If anyone wants to play with the script that generated the results above, here it is: #!/bin/bash ### Edit the following line so that TESTCVSROOT has a valid value TESTCVSROOT=/path/to/test/cvs/repository # If you want to see cvs's output, set OUT to /dev/fd/1, # or delete all occurrences of $OUT in the code below OUT=/dev/null rm -rf $TESTCVSROOT cvs -d $TESTCVSROOT init $OUT ### First iteration rm -rf Foo mkdir Foo cd Foo echo -n 0 bar cvs -d $TESTCVSROOT import -m '' Foo vendor_1 v1 $OUT cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo cd .. ### Second iteration rm -rf Foo mkdir Foo cd Foo echo -n 1 bar cvs -d $TESTCVSROOT import -m '' Foo vendor_1 v2 $OUT cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo mv bar bar.orig cvs -d $TESTCVSROOT checkout -d . -r vendor_1 Foo diff bar bar.orig echo $? cd .. exit 0 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help! Branch/attic mess
Cc: [EMAIL PROTECTED] From: Mark D. Baushke [EMAIL PROTECTED] [EMAIL PROTECTED] writes: From: Mark D. Baushke [EMAIL PROTECTED] ... cvs checkout -d top . # checkout all of your modules Wow. I've never before seen '.' used in the modules slot for checkout. I just scoured the manual trying to find documentation on this, but no luck. Is this usage documented anywhere? I don't recall it being explicitly mentioned. However, the cvs-1.11.16/src/sanity.sh uses th is in many tests including the basica test, so I don't think of it as being all that secret. *Finally* I get it. . refers to $CVSROOT/. Doh! I tend to forget that, at least as far as cvs checkout is concerned, Project is pretty much equivalent to any directory under $CVSROOT. I.e. cvs checkout -d top . and cvs checkout -d top ././/.///CVSROOT/.././ and even (lo and behold) cvs checkout -d top '' have the exactly same effects. Actually, the above was a bit of an overstatement. Maybe it should be rephrased as Project is pretty much equivalent to any directory under $CVSROOT, or a module mentioned in $CVSROOT/modules kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
cvs checkout: move away foo; it is in the way
OK, here's an interaction that illustrates yet another bizarre (to me) CVS conundrum (summary: I import some files, create a branch, modify one file on this branch, commit it, delete the CVS directory, and reimport): % export CVSROOT=/home/jones/cvs_test % rm -rf $CVSROOT % cvs init % mkdir Foo % cd Foo % touch foo % cvs im -m '' Foo vendor_1 v1 N Foo/foo No conflicts created by this import % cvs co -d . Foo cvs checkout: Updating . U foo % cvs ta -b branch_1 cvs tag: Tagging . T foo % cvs co -d . -r branch_1 Foo cvs checkout: Updating . % date % cvs ci -m '' foo Checking in foo; /home/jones/cvs_test/Foo/foo,v -- foo new revision: 1.1.1.1.2.1; previous revision: 1.1.1.1 done % rm -rf CVS % cvs im -m '' Foo vendor_2 v2 U Foo/foo No conflicts created by this import % cvs co -d . -r vendor_2 Foo cvs checkout: Updating . cvs checkout: move away foo; it is in the way C foo Why am I getting the error message cvs checkout: move away foo; it is in the way? Can anyone make any sense of this? Thanks! kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Help! Branch/attic mess
I am a CVS newbie, and I'm having a very hard time with some very basic CVS concepts. The interaction below illustrates the sources of my confusion. Basically, I start a project Foo which initially consists of a single file foo. Afterwards, I add and commit a new file bar. Finally, I issue a cvs status -v command. (I've numbered the lines and inserted a few comments, preceded by ###). 1 % CVSROOT=/home/jones/cvs_test 2 % rm -rf $CVSROOT/Foo 3 % mkdir -p Foo rm -rf Foo/* 4 % cd Foo 5 ### generate a file for CVS to act on 6 % touch foo 7 ### import and check out 8 % cvs -d $CVSROOT im -m '' Foo trunk start 9 N Foo/foo 10 11 No conflicts created by this import 12 13 % cvs -d $CVSROOT co -d . Foo 14 cvs checkout: Updating . 15 U foo 16 ### modify a CVS-controlled file 17 ### create a new file to put under CVS control 18 % touch bar 19 % cvs ad bar 20 cvs add: scheduling file `bar' for addition 21 cvs add: use 'cvs commit' to add this file permanently 22 % cvs ci -m '' bar 23 RCS file: /home/jones/cvs_test/Foo/bar,v 24 done 25 Checking in bar; 26 /home/jones/cvs_test/Foo/bar,v -- bar 27 initial revision: 1.1 28 done 29 % cvs st -v 30 cvs status: Examining . 31 === 32 File: bar Status: Up-to-date 33 34 Working revision:1.1 Thu Jun 3 15:22:24 2004 35 Repository revision: 1.1 /home/jones/cvs_test/Foo/bar,v 36 Sticky Tag: (none) 37 Sticky Date: (none) 38 Sticky Options: (none) 39 40 Existing Tags: 41 No Tags Exist 42 43 === 44 File: foo Status: Up-to-date 45 46 Working revision:1.1.1.1 Thu Jun 3 15:22:22 2004 47 Repository revision: 1.1.1.1 /home/jones/cvs_test/Foo/foo,v 48 Sticky Tag: (none) 49 Sticky Date: (none) 50 Sticky Options: (none) 51 52 Existing Tags: 53 start (revision: 1.1.1.1) 54 trunk (branch: 1.1.1) 55 OK, what puzzles me about this is that bar is not associated with *any* branch, whereas foo is. This makes absolutely no sense to me. What gives? I tried to repeat everything above, but this time specifically requesting the branch called trunk at checkout time (line 15). 1 % CVSROOT=/home/jones/cvs_test 2 % LAB=/home/jones/cvslab 3 % cd /home/jones/cvslab 4 % rm -rf $CVSROOT/Foo 5 % mkdir -p Foo rm -rf Foo/* 6 % cd Foo 7 ### generate a file for CVS to act on 8 % touch foo 9 ### import and check out, explicitly requesting the trunk branch 10 % cvs -d $CVSROOT im -m '' Foo trunk start 11 N Foo/foo 12 13 No conflicts created by this import 14 15 % cvs -d $CVSROOT co -d . -r trunk Foo 16 cvs checkout: Updating . 17 U foo 18 ### modify a CVS-controlled file 19 ### create a new file to put under CVS control 20 % touch bar 21 % cvs ad bar 22 cvs add: scheduling file `bar' for addition on branch `trunk' 23 cvs add: use 'cvs commit' to add this file permanently 24 % cvs ci -m '' bar 25 RCS file: /home/jones/cvs_test/Foo/Attic/bar,v 26 done 27 Checking in bar; 28 /home/jones/cvs_test/Foo/Attic/bar,v -- bar 29 new revision: 1.1.2.1; previous revision: 1.1 30 done 31 % cvs st -v 32 cvs status: Examining . 33 === 34 File: bar Status: Up-to-date 35 36 Working revision:1.1.2.1 Thu Jun 3 15:23:13 2004 37 Repository revision: 1.1.2.1 /home/jones/cvs_test/Foo/Attic/bar,v 38 Sticky Tag: trunk (branch: 1.1.2) 39 Sticky Date: (none) 40 Sticky Options: (none) 41 42 Existing Tags: 43 trunk (branch: 1.1.2) 44 45 === 46 File: foo Status: Up-to-date 47 48 Working revision:1.1.1.1 Thu Jun 3 15:23:11 2004 49 Repository revision: 1.1.1.1 /home/jones/cvs_test/Foo/foo,v 50 Sticky Tag: trunk (branch: 1.1.1) 51 Sticky Date: (none) 52 Sticky Options: (none) 53 54 Existing Tags: 55 start (revision: 1.1.1.1) 56 trunk (branch: 1.1.1) Now the results are even more puzzling. For starters, when bar is commited, its corresponding RCS file bar,v is (inexplicably) placed under $CVSROOT/Foo/Attic. Moreover, and just as inexplicably, a second branch (1.1.2) emerges. So now there are two branches associated with the same tag trunk, depending on which file one looks at. The relationship between these two branches is a mystery to me. If someone can explain to me what's going on I'd be most grateful. Many thanks, kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo
Re: Help! Branch/attic mess
From: Jim.Hyslop [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 12:28:27 -0400 [EMAIL PROTECTED] wrote: The interaction below illustrates the sources of my confusion. Basically, I start a project Foo which initially consists of a single file foo. Afterwards, I add and commit a new file bar. Finally, I issue a cvs status -v command. (I've numbered the lines and inserted a few comments, preceded by ###). [...] 7 ### import and check out 8 % cvs -d $CVSROOT im -m '' Foo trunk start There's the root of your confusion. The import command is intended to import third-party software into your repository, not to create your own project. OK, but how does one get a project started without using import? The Cederqvist manual gives no other way to start a project besides using import (ch. 3). And going over all the commands listed with cvs --help-commands, I don't see any other command to start a project with. Many thanks for the other clarifications. It all makes a *lot* more sense now. BTW, what got me started looking into all this was trying to find some algorithm for determining the branch (if any) a given checked out revision belongs to, based on the info genertated by cvs status -v. As best as I can figure, this is the algorithm: remove the last period and everything that follows it from the Working revision; call this the branch revision if there is a branch tag, among those listed under Existing Tags corresponding to the branch revision, then the checked out revision under consideration belongs to it. if not, the checked out revision belongs to no branch (i.e. it belongs to the trunk). (As far as I have seen, these cases correspond to branch revisions with no periods in them.) This algorithm is correct for all the cases I've checked, but I can't say whether it is correct in general. Thanks! kj ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help! Branch/attic mess
X-Original-To: [EMAIL PROTECTED] From: Jim.Hyslop [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 14:43:14 -0400 [EMAIL PROTECTED] wrote: OK, but how does one get a project started without using import? The Cederqvist manual gives no other way to start a project besides using import (ch. 3). And going over all the commands listed with cvs --help-commands, I don't see any other command to start a project with. That's because there is no single command to do that. You need to add an entry to the CVSROOT/modules file, then create the corresponding directory in the repository and check it out. From there, you use 'cvs add'. I suppose I could always do something like % cvs im -I'*' -I'.*' -m '' Foo x xx Surprisingly enough (to me at least), if I do this, then afterwards CVS doesn't even recognize the vendor tag: % cvs co -d . -r x Foo cvs [checkout aborted]: no such tag x BTW, what got me started looking into all this was trying to find some algorithm for determining the branch (if any) a given checked out revision belongs to, based on the info genertated by cvs status -v. As best as I can figure, this is the algorithm: [etc]. Wouldn't it just be easier to look at the sticky tags field of the status report? Or am I missing something here? No, except for my uncanny talent for making things more complicated than they need to be :) . Thanks! kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help! Branch/attic mess
From: Jim.Hyslop [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 14:43:14 -0400 [EMAIL PROTECTED] wrote: BTW, what got me started looking into all this was trying to find some algorithm for determining the branch (if any) a given checked out revision belongs to, based on the info genertated by cvs status -v. As best as I can figure, this is the algorithm: [etc]. Wouldn't it just be easier to look at the sticky tags field of the status report? Or am I missing something here? Now I remeber why I was not looking at the sticky tag field: it doesn't necessarily contain the *branch* tag (it can contain a revision tag, in which case I don't see any way around deducing the branch tag from the working revision number, as I described). kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help! Branch/attic mess
From: Mark D. Baushke [EMAIL PROTECTED] [EMAIL PROTECTED] writes: OK, but how does one get a project started without using import? A typical set of commands might be CVSROOT=/path/to/your/repository; export CVSROOT cvs init# create the repository and the CVSROOT module cvs checkout -d top . # checkout all of your modules Wow. I've never before seen '.' used in the modules slot for checkout. I just scoured the manual trying to find documentation on this, but no luck. Is this usage documented anywhere? BTW, what got me started looking into all this was trying to find some algorithm for determining the branch (if any) a given checked out revision belongs to, based on the info genertated by cvs status -v. You may find looking in the sources cvs-1.11.16/doc/RCSFILES of interest. Thanks for the pointer. kynn ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
How to expunge sick revision?
I used cvs remove to get rid of some unwanted files, and CVS informed me to use commit to make the removals final. OK, so I did cvs commit, and CVS proceeded to commit everything in sight, not just the removals as it had announced. Among the files it committed was a source file in a completely sick and dangerous state (it contains a potentially devastating bug). So now this completely sick file is indelibly enshrined in the repository. It is simply obscene to have such potentially dangerous code stored in the repository, but as far as I've been able to find there is nothing I can do about it. OK, fine. Life is too short, etc., and I try to get on with mine by reverting to an earlier (non-buggy) revision of the rotten file; I pull it out with cvs update -r x.x. I make some changes, but when I try to commit them, I get: cvs commit: sticky tag `x.x' for file `BloodyMurder.c' is not a branch So the completely rotten version x.(x+1) that should have never been stored in the repository in the first place is now blocking my attempts to commit a correct revision. How can I fix this horrible mess? Thanks, Kynn PS: Please, Cc me in your replies. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Newbie: nonsensical documentation
I'm being forced by my supervisor to start using CVS, which I hate. The reason I hate it is that every time I've tried to read the documentation I've found it either incomprehensible or unreliable. In my experience, this is par for the course for free software, and that's why I don't touch it with a ten-foot pole. But now my job depends on it, so I desperately need every bit of help I can get... On page 29, one is instructed to do this: $ cd $WDIR $ cvs import -m Imported sources yoyodine/$RDIR yoyo start $ cd .. I've done this (though, of course, I've changed yoyodine/$RDIR to MyModule, and yoyo to $USER). Next, the instructions say to do try this: $ cvs checkout yoyodine/$RDIR so I try: $ cvs -n checkout MyModule but I get an error message: cvs checkout: cannot chdir to MyModule: Not a directory cvs checkout: ignoring module MyModule Why am I getting the cannot chdir error message? My CVSROOT variable is properly set, and the directory $CVSROOT/MyModule exists: % ls -ld $CVSROOT/MyModule drwxrwsr-x3 kynn cvs 4096 Mar 11 11:49 /usr/local/cvsroot/MyModule Thank you for all your help. kj P.S. please Cc me in your replies. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
New to CVS: multiplatform projects
I'm new to CVS, and version control in general. I understand the basic idea of having a repository that preserves the history over time of a software project. My problem is that, for reasons too complex to go into here, I must manage two parallel Java development projects. These two projects are 99 % identical, except in the few areas in which one must be compatible with v. 1.1.8 of the JDK, and the other must be compatible with v. 1.3 of the JDK. The v. 1.3 branch is our main area of development, while the v. 1.1.8 one is a secondary effort to satisfy a significant fraction of our customers who have not upgraded from Mac OS 9 to Mac OS X. Since the two versions are so similar, it would be convenient to generate the v. 1.1.8 code by applying patches to the v. 1.3 code. (If this were C/C++, the situation could be handled trivially with conditional compilation, but, alas, Java does not have conditional compilation.) This seems like a problem well suited to CVS, but all the introductory material I've read so far centers around the problem updating versions over time, instead of the problem of generating one secondary version from a primary one. It seems to me that, schematically, things would look like this: 1.3-branch-1.1 --1.1.8-branch-1.1 (patch) | v 1.3-branch-1.2 --1.1.8-branch-1.2 (patch) . . . . . . Hence, CVS would have to keep track of not only the diffs between successive versions of the 1.3-branch code, but also the diffs between the 1.1.8-branch and the 1.3 branch. (It is not clear to me whether it would be useful to keep track of the diffs between successive 1.1.8-branch versions, even if it were possible). Can CVS be cajoled into helping with such a problem? Thanks, KJ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
