Hi, Terry: Terry Spafford wrote: > Sorry if this gets out twice, got an error when I tried to send this > before so I suspect I had something misconfigured at first. > > I've been experimenting with CVS import and I noticed some wierd > behaviour. I'm not sure if it is due to me not knowing how to use it > properly, or trying to do something that it isn't supposed ot be doing or > what. > > Anyways, I did the following. > > I had a directory mk containing the files Makefile, suffix.mk and > prefix.mk I wanted to import as a new CVS repository. > > I did the following commands from within that mk directory: > > cvs import -m "New CVS tree" mk new_branch start >
[...] > If I now checkout that code with the new_branch tag (cvs co -r new_branch > mk ) and make a change to a different file, and commit it, that change > goes in on the branch (good) but it also goes in on the trunk as well (not > so good/confusing). However if I make a change to the file I previously > changed on the trunk, the change only goes in on the branch; it doesn't > overwrite the one of the trunk. (As expected) > > My confusion comes from the middle case. Why is it that when I make a > change to a file on that particular branch that has not been changed on > the trunk, the trunk will now see those changes? > You have find a magic on the vendor branch. The short answer, don't do that. The long one, I don't know what's happening, your middle case shouldn't work this way (unless you've forgotten to tell us something relevant). As per the usual way branches work if you checkout -r branchtag (as new_branch is) your sandbox should be "stickied" to that branch so all further commits should go *only* to the tip of that branch. > Is there any easy way to not have this happen? Or should I simply get used > to having an unused branch hanging around in all my projects (and have the > branch labeled as unused so people don't try to check it out) > As you probably know, the import command is kind of a magic so you can... 1/ Start a new repo/module using a ton of files you already have. 2/ Managing the vendor branch concept (so you can "add" from time to time third-party sources). The question here is that you don't *need* to import in order to populate a new repo/module. In your example case you only imported three files on a single directory. You can get yourself freed from that branch by not importing. For a few files, you can `cvs add` by hand, for bigger projects you can program a rather easy script to do it for you. > Also, with respect to version numbers, if I were to manually increase the > version of the trunk from 1.# to 2.0, would all the branches that were off > of it (as 1.1.1.2.# etc....) stay the same? What if I did it the other way > (increased a branch's version to 2.1.1.2.0 while leaving the trunk as 1.#) > ? The short answer (again): don't do that. Forget about file revision numbers, they're not for human consumption. Use always simbolic tags both to refer to branches (like talking about "new_branch" instead of the 1.1.1 branch) and keystones on the history of your sources (like the "start" tag on your "new_branch" branch). The long answer you can find in the cvs docs. -- SALUD, Jesus *** [EMAIL PROTECTED] *** Desde Zaragoza, busco empleo - http://www.geocities.com/jesusm_navarro/CV/cv.html *** _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
