why does HEAD behave as a tag rather than as a branch?
It is confusing to the users that they can't just do cvs up -r $BRANCH all the time. It also forces a lot of scripts into clumsy workarounds (if $tag == "" then $tag == "HEAD"). Is there a way to "fix" this? tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
cvs bubbles faq-o-matic gone?
http://www.loria.fr/~molli/cvs-index.html now sez: " I have no more time to maintain the CVS bubbles page. Please use this link instead. CVS HOME. " However the cvshome fom (https://ccvs.cvshome.org/fom/cache/1.html) doesn't seem to contain the contents of the old cvs bubbles fom. Is there any chance the old data could be migrated? That fom had a lot of good information in it (including a canonical answer for "how do i rename files" that was better than https://ccvs.cvshome.org/fom/fom.cgi?_highlightWords=rename&file=140). It would be sad if all that info is gone forever. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem creating tag on branch where HEAD has deleted directory
On Tue, Oct 12, 2004 at 12:31:14PM -0400, Christopher W. Farnham wrote: > I'm in a jam while trying to use the 'cvs tag' command on a branch which > contains a directory now deleted in the HEAD branch. > > My output looks like this: > |[EMAIL PROTECTED] contentcontroller]$ cvs tag -Ff R3-1 > cvs tag: failed to create lock directory for > `/usr/local/cvs/wrycanCode/wrycan/contentcontroller/src/java/com/wrycan/contentcontroller/cvsclient' > > (/usr/local/cvs/wrycanCode/wrycan/contentcontroller/src/java/com/wrycan/contentcontroller/cvsclient/#cvs.lock): > > No such file or directory > cvs tag: failed to obtain dir lock in repository > `/usr/local/cvs/wrycanCode/wrycan/contentcontroller/src/java/com/wrycan/contentcontroller/cvsclient' > cvs [tag aborted]: read lock failed - giving up > > |Any ideas how I can get around this? The 'cvsclient' directory is > removed from HEAD but still exists in my branch. This shouldn't happen unless you completely removed the directory from the repository, which is generally a Bad Idea. If you just cvs delete'd it, the files would have moved to the Attic and the directory would still exist in the repository. Either way, how about cvs add'ing that directory back on the HEAD, which will re-create the directory in the repository, and unblock you. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Need suggestion regarding CVS
> [EMAIL PROTECTED] wrote: > > (each of them shouldn't be more than a few megabytes). My question is > > if I setup a CVS server on my linux box, would the administration of > > the server be a real pain in the butt and a drain on my cpu resources? > > I don't know much about running a cvs server but am eager to learn, > > only question is whether it would take up too much of my cpu's > > resourses. If you have any plans of pursuing a job in software, having some actual, hands-on experience with source control is a big plus. Doing light cvs administration isn't that hard, and will give you more in-depth knowledge into how source control works. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to do an rcs revert?
On Fri, Jul 16, 2004 at 09:53:28AM -0400, Larry Jones wrote: > > Mike wrote: > > > Given a project a that has the path a/b/c/d and a file a/b/c/d/file1, > > > you check in file1, then make a change, check in the change, then > > > want to revert to the original version, how do you do it? > > > > Use the -p and -r options: > > > > cvs update -p -r1.1 file1 > file1 > > > > then check it in again. > > Or use update with two -r options (note that the order is important): > > cvs update -rHEAD -r1.1 file1 > > then check it in again. Don't you mean two -j options? cvs update -jHEAD -j1.1 file1 tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Changes made to project
Please don't top-post. > Jim.Hyslop wrote: > >Murrgon wrote: > > > >>Is there a way to determine if there have been any commits or adds > >>done to a project since a specific date or tag? > > > > > >Do you mean besides using the -r or -d options to diff/log/update? On Wed, Jul 14, 2004 at 03:07:22PM -0400, Murrgon wrote: > Hmmm, yeah I think I'm gonna need some different method. The problem > is that the machine doing the check for differences does not have the > project checked out to a sandbox so doing a diff won't work. But it could have a sandbox checked out, which would make everything easier. > Bascially what I want to do is set up a build machine that can check > for changes made to the project, and if there are any it will check > out the code and build it. It does a fresh check out each time and > wipes the sandbox after it is finished. Don't write this yourself. Many, many projects already scratch this itch (cruisecontrol, anthill, gump -- these are all java-affiliated, but surely billions more exist for your language of choice). tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: What is yoyodyne? :)
On Tue, Jul 13, 2004 at 07:02:20AM -0700, [EMAIL PROTECTED] wrote: > > My question is historical. I am a Tomas Pynchon fan and I meet first > > time 'yoyodyne' word in his book called "V". In his book 'yoyodyne' is > > a name of hi-tech corporation. Next time I see this word in CVS manual > > (as an example of path ?yoyodyne/tc?) I want to know is CVS autors > > Pynchon fans too? Or it is some kind of coincidence? > > I've always knows 'Yoyodyne' as a Buckaroo Banzi reference. I'm thinking > you are right about Pynchon, as this seems to predate the film. > > Here are references for you: > http://www.figmentfly.com/bb/q40.html > http://www.figmentfly.com/bb/q31.html Yoyodyne also appears in Pynchon's _The Crying of Lot 49_. Both novels predate BB (GR: 1963; CoL49: 1966). Yoyodyne is a propulsion systems company in each case. I also enjoy this definition: " YOYODYNE: the amount of force required to impart an acceleration of one centimeter per second per second to a yo-yo with a mass of one gram (cm/g/sec). " --http://wso.williams.edu/~cwilliam/stomach/yoyo.html So anyway, were the cvs documentarians John Lithgow fans or Oedipa Maas fans or neither or both? Surely there's someone on this list grizzled enough to remember. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
determine branch's ancestor?
I have been negligent in my record-keeping and find that i don't know from what branch i cut a new branch. That is, did i cut feature branch FEATURE from the trunk, or from release branch RELEASE? Most of the work on FEATURE touches new files or files that haven't changed in months, so the branch tags RELEASE and FEATURE both point to the same versions of the files (the last HEAD revision), so i can't use that to help me determine the ancestor. How else can i do this? tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branch merging to main trunk
On Thu, Jul 01, 2004 at 08:35:54AM -0700, Christophe Delarue wrote: > Once a branch is created, bug are corrected on the branch and then > merged into the main trunk. > > How do you deal with those merges : > > 1) On each release of the branch, done by the leader of the branch as > describe in http://www.magic-cauldron.com/ > > using cvs update -j last_release -j new_release on a main trunk > sandbox It seems this is the best bet. > 2) Each week/3 days, the modifications are merge back into the main > trunk by using the update -r new_release on a main trunk sandbox This won't work; instead it will update your trunk sandbox to be a branch sandbox. > 3) each time a developper corrects a bug, (s)he has to merge it into > the main trunk. > To ensure the bug migration, a check could occur by verifying the log > on commit : on bug correction the bug id has to be in the comment. > When the bug is merged, the following commit follow the same > convention. Therefore we can track in the log the bug migration. I tried this policy for a while, but unless you have a tiny team of very disciplined developers, someone will forget, or bungle a merge, and changes will get missed. Having validation would help, but i still think this is impossible in practice. > 4) a rdiff is done between the last bug migration on the branch : > cvs rdiff -r last_release -r new_release myproj > this diff is collected, each is validated, and through a sh script the > migration is done file by file through a > cvs update -j -j > foo/bar/file.x This is the same as #1, but with a lot more overhead. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
On Tue, Jun 08, 2004 at 09:21:31AM -0700, John Hanny wrote: > I'd like a cvs command that tells me what files in the current > directory are new. One hack that I've been using is "cvs update." The > files that are prefixed by '?' are new. Unfortunately, this has the > side-effect of updating my local directory files if they have been > changed in the repository. Is there another way to do what I need to > do without causing the udpates? cvs -n update tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How safely "move" files from one branch to the other?
On Fri, Jun 18, 2004 at 02:48:42PM +0200, marko wrote: > I've a directory with a few files. There exist 2 branches for this > directory, say A and B. > > I checked out the branch A and committed the changes. Only then I noticed > that I should have modified branch B instead. > > How do I safely "move" the files from branch A to branch B? For a small change like this, it's easiest to: - back out the changes from branch A (in A sandbox) cvs up -j[new rev] -j[previous rev] [list of files] (verify changes and commit) - merge changes into branch B (in B sandbox) cvs up -j[previous rev] -j[new rev] [list of files] (verify changes and commit) Note that [previous rev] and [new rev] can be tags, which may make the process a little less cumbersome. HTH, tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to undo a change to a branch
On Tue, Jun 15, 2004 at 02:12:42PM -0400, Kynn Jones wrote: > 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.) cvs up -j[revision including change you didn't mean to commit] -j[revision before change you didn't mean to commit] filename will merge out the change you meant to get rid of. Sanity check the file, then commit it. Easy as pie. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ci/co on HEAD for specific files in a branch?
On Mon, Jun 14, 2004 at 11:43:45AM -0400, Doug Lee wrote: > Is there a way for me to specify that certain files should checkout > when I checkout a branch but should commit to the trunk when > committed? In other words, I have one or more branches that contain a > few files that should have only one development path. Specifically, > the HTML document describing the project should not branch but should > be a part of all branches along with the code. I'm not sure i understand the problem, but the stickiness of branch tags may help you. If you set up your sandbox with all your files checked out from the appropriate branches, commits will all go to the right places. E.g.: cvs up -rbranch1 file1 cvs up -rbranch2 file2 cvs up -A file_from_trunk When you commit, file1's change will be committed to branch1, file2's to branch2 and file_from_trunks to the trunk. Is this what you're looking for? If you need to reproduce it, you could write a script to do the initial checkout. Note that this approach is awfully fragile, perhaps even dangerously so, especially if you expect a whole room full of developers to do it without errant commits. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: overwrite a branch?
On Tue, Jun 01, 2004 at 01:35:22PM -0700, Tyler wrote: > We've been working on two branches for several months: the trunk (our > good pal HEAD) and the release branch (RELEASE). > > Initially, the plan was for developers to make any needed changes to > both HEAD and RELEASE. RELEASE would eventually be released, while HEAD > would be the development branch, from which RELEASE2 would eventually be > branched. > > Somewhere in there, we changed our branching/releasing strategy, and the > release branch got to be very long-lived, such that now we don't want to > go back to the code on the HEAD. Instead, we want to continue working > off of RELEASE, and eventually branch RELEASE2 from the code in RELEASE. > > For various reasons, i believe that promoting RELEASE up to HEAD is a > good idea (mostly related to low level cvs management and > administration). > > Question 1: am i right to want to do this? > > The best way i can think of to do this is by essentially overwriting > HEAD with RELEASE. I don't want to do a merge, because HEAD is > considered unstable (it hasn't been tested for months), and because what > i want is precisely what's on RELEASE. > > Question 2: is there a better way to do this than overwriting HEAD with > RELEASE? > > The best way i can think of to do the overwrite is with rsync. > Basically, the methodology would be: > > - freeze HEAD > - clean checkout of HEAD > - tag it :) > > - clean checkout of RELEASE > - tag it > - copy all files in RELEASE sandbox over to HEAD sandbox > - use rsync --delete to catch files that have been deleted on > RELEASE but that have not had that change propagated to HEAD > > Question 3: is this totally insane? Is there a better way to do the > actual overwrite? While i would still be interested in opinions about questions 1 and 2, a friend of mine appears to have solved question 3. This: cvs up -jHEAD -jRELEASE -kk appears to have had the desired overwriting effect with no conflicts. I'm still trying to figure out how it works, so i'm not sure i trust it, but this: cvs diff -rRELEASE -kk from the merged-into working directory returns no diffs. Question 3a: does this make sense? Or is there something subtle that might have gone wrong -- even so subtle as to fool cvs diff? Thanks, tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
overwrite a branch?
We've been working on two branches for several months: the trunk (our good pal HEAD) and the release branch (RELEASE). Initially, the plan was for developers to make any needed changes to both HEAD and RELEASE. RELEASE would eventually be released, while HEAD would be the development branch, from which RELEASE2 would eventually be branched. Somewhere in there, we changed our branching/releasing strategy, and the release branch got to be very long-lived, such that now we don't want to go back to the code on the HEAD. Instead, we want to continue working off of RELEASE, and eventually branch RELEASE2 from the code in RELEASE. For various reasons, i believe that promoting RELEASE up to HEAD is a good idea (mostly related to low level cvs management and administration). Question 1: am i right to want to do this? The best way i can think of to do this is by essentially overwriting HEAD with RELEASE. I don't want to do a merge, because HEAD is considered unstable (it hasn't been tested for months), and because what i want is precisely what's on RELEASE. Question 2: is there a better way to do this than overwriting HEAD with RELEASE? The best way i can think of to do the overwrite is with rsync. Basically, the methodology would be: - freeze HEAD - clean checkout of HEAD - tag it :) - clean checkout of RELEASE - tag it - copy all files in RELEASE sandbox over to HEAD sandbox - use rsync --delete to catch files that have been deleted on RELEASE but that have not had that change propagated to HEAD Question 3: is this totally insane? Is there a better way to do the actual overwrite? TIA for any advice, tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using shared library in gCvs
On Wed, May 26, 2004 at 11:23:48AM -0400, cvsnewbie wrote: > >>I had compiled my gCvs and tcl using sources from sourceforge. When I > >>ran it, I got the shared library libtcl8.4.so file not found error. I > >>did have the so file in the /usr/local/lib directory. Is there an > >>environmental variable like LIB (under RedHat Linux) needed to be > >>defined? > >> > >>TIA. > >> > >>P.S. I looked at the gCVS's Makefile. In there is a variable called > >>libtclxx.so defined, but is not referred. Could I make some change to > >>the command file to link the libtclxx.so file directly to the gCvs > >>executable? > > Nevermind now, I put the so file in the /usr/lib folder. Still, anyway > to control the path? Look at /etc/ld.so.conf and man ldconfig. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Error during merge
On Mon, May 24, 2004 at 03:52:56PM -0400, [EMAIL PROTECTED] wrote: > I'm merging branchY into branchX via > > > cvs -nq update -j b_branchX -j b_branchY proj > > (I use the -nq so it does do the update yet ) and I get > > retrieving revision 1.2.4.2 > retrieving revision 1.2 > Merging differences between 1.2.4.2 and 1.2 into file1.cpp > cvs update: file1.cpp: No such file or directory cvs -n does not play nice with merges. I think this is because -n prevents cvs from doing anything, including creating the temp files it needs to do its merges. Instead of the -n, do the merge in a nice, safe sandbox. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
get cvs log to show nothing if a file isn't on a branch?
I'm using cvs log to aggregate logs of what has gone into a specific build (determined by datespec). I'm only interested in one branch at a time. The log invocation is something like this: cvs -q log -N -r$BRANCH -d "$DATE1<$DATE2" The problem is that if a file doesn't exist on $BRANCH (like it was added to the trunk sometime after the branch was cut), cvs log returns that file's entire history. I can't actually imagine a scenario where you'd want the entire history for a file just because it doesn't meet your filtering criteria. I'm most willing to accept that it's because rlog is old and was written in the halcyon days of heavy cocaine use amongst UNIX developers. But is there a way to suppress this behavior? Am i going to have to add logic that looks at all the tags associated with the file and ignores cvs log's output if $BRANCH doesn't show up there? Is there an easier way? TIA, tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff: Include contents of added files?
On Wed, May 05, 2004 at 08:28:10PM +0200, Toralf wrote: > When I run 'cvs diff' on a directory where a new file has been added, > but not commited, the output will contain a line saying > > cvs server: tst.c is a new entry, no comparison available > > (if the name of the file is tst.c) > > Is it possible to have the compelete contents of the file listed as > added lines instead? Differently put, can I get cvs to include the output of > diff /dev/null tst.c > instead of printing the above mentioned message? Try -N. tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merging delta between two revisions down to trunk doesn't work (was (no subject))
Forgot the subject before. Whoops. It turns out my test case was too simple, and this was a pathological case for the diff/patch step, because there wasn't any context. I'm still not sure why the text from 1.1.2.1 ends up in the conflict section in the merged result, but that's likely not a cvs problem. tyler On Wed, Apr 21, 2004 at 03:06:48PM -0700, Tyler wrote: > Sorry this is long, but i'm hoping this is an instructive example. > > I'm trying to take the delta between two revisions of a file on a branch > and merge that delta onto the trunk. This doesn't seem to work: > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs status test > === > File: test Status: Up-to-date > >Working revision:1.1 >Repository revision: 1.1 /cvsroot/sandbox/troscoe/test,v >Sticky Tag: (none) >Sticky Date: (none) >Sticky Options: (none) > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -j1.1.2.1 -j1.1.2.2 test > RCS file: /cvsroot/sandbox/troscoe/test,v > retrieving revision 1.1.2.1 > retrieving revision 1.1.2.2 > Merging differences between 1.1.2.1 and 1.1.2.2 into test > rcsmerge: warning: conflicts during merge > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cat test > trunk line 1 > <<<<<<< test > === > branch line 1 > branch line 2 > >>>>>>> 1.1.2.2 > > > > Two questions: > > 1. Why is a conflict being generated, especially considering that the > top half of the conflict is with nothing. > > 2. Why does "branch line 1" (from 1.1.2.1) come along for the ride when > i do this merge? > > > Here's a painfully complete picture of the test environment: > > ### set up a simple test file > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ echo "trunk line 1" > test > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs add test > cvs add: use 'cvs commit' to add this file permanently > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs commit -m "test file initial revision" > test > RCS file: /cvsroot/sandbox/troscoe/test,v > done > Checking in test; > /cvsroot/sandbox/troscoe/test,v <-- test > initial revision: 1.1 > done > > > ### branch it > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs tag -b BRANCH test > T test > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -rBRANCH test > > ### check in a couple changes on the branch > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ echo "branch line 1" >> test > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs commit -m"branch line 1" test > Checking in test; > /cvsroot/sandbox/troscoe/test,v <-- test > new revision: 1.1.2.1; previous revision: 1.1 > done > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ echo "branch line 2" >> test > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs commit -m"branch line 2" test > Checking in test; > /cvsroot/sandbox/troscoe/test,v <-- test > new revision: 1.1.2.2; previous revision: 1.1.2.1 > done > > ### so here's what things look like: > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -r1.1 -p test > trunk line 1 > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -r1.1.2.1 -p test > trunk line 1 > branch line 1 > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -r1.1.2.2 -p test > trunk line 1 > branch line 1 > branch line 2 > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs diff -u -r1.1 -r1.1.2.1 test > Index: test > === > RCS file: /cvsroot/sandbox/troscoe/test,v > retrieving revision 1.1 > retrieving revision 1.1.2.1 > diff -u -u -r1.1 -r1.1.2.1 > --- test21 Apr 2004 20:56:40 - 1.1 > +++ test21 Apr 2004 20:58:35 - 1.1.2.1 > @@ -1 +1,2 @@ > trunk line 1 > +branch line 1 > > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs diff -u -r1.1.2.1 -r1.1.2.2 test > Index: test > === > RCS file: /cvsroot/sandbox/troscoe/test,v > retrieving revision 1.1.2.1 > retrieving revision 1.1.2.2 > diff -u -u -r1.1.2.1 -r1.1.2.2 > --- test21 Apr 2004 20:58:35 - 1.1.2.1 > +++ test21 Apr 2004 20:59:51 - 1.1.2.2 > @@ -1,2 +1,3 @@ > trunk line 1 > branch line 1 > +branch line 2 > > ### i can merge any contiguous parts of the branch back down to the trunk > [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs status test > === &
(no subject)
-j1.1.2.2 -j1.1.2.1 test RCS file: /cvsroot/sandbox/troscoe/test,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.1 Merging differences between 1.1.2.2 and 1.1.2.1 into test [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cat test trunk line 1 branch line 1 ### and roll back some more [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -j1.1.2.1 -j1.1 test M test RCS file: /cvsroot/sandbox/troscoe/test,v retrieving revision 1.1.2.1 retrieving revision 1.1 Merging differences between 1.1.2.1 and 1.1 into test [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cat test trunk line 1 ### but this doesn't work, and i don't understand why [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs status test === File: test Status: Up-to-date Working revision:1.1 Repository revision: 1.1 /cvsroot/sandbox/troscoe/test,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cvs up -j1.1.2.1 -j1.1.2.2 test RCS file: /cvsroot/sandbox/troscoe/test,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 Merging differences between 1.1.2.1 and 1.1.2.2 into test rcsmerge: warning: conflicts during merge [EMAIL PROTECTED]:~/src/sandbox/troscoe]$ cat test trunk line 1 <<<<<<< test === branch line 1 branch line 2 >>>>>>> 1.1.2.2 Is there no way to take the delta between two revisions and merge those onto another branch? Do i have to merge the entire branch down if i want to do this? Thanks! tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
