Date: Mon, 17 Mar 2003 17:59:37 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <3E765359.7FC6C541@bellatlantic.net> References: <3E73DCF7.80490FA6@bellatlantic.net> <15988.49648.483313.383942@emerger.yogotech.com> <3E74CC37.DF83EE46@bellatlantic.net> <3E750471.3498C9BE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > Sergey Babkin wrote: > > Nate Williams wrote: > > [ ... "CVS cache and cache coherency" ... ] > > > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. Now I have to use RCS > > locally for the temporary in-delevopment versions of file. Would > > be nice to have a kind of a local branch which can be later committed > > as a whole - in one commit per file, or by duplicating all the > > intermediate versions with their messages. > > Not really possible, without CVSup coming onto a vendor branch instead Actually, I was thinking of the opposite: doing all the changes on a vendor branch (or in some separate local repository altogether), then merging them into the main branch. Think of the following sequence that can be used now: cvs co rcs ci # save the baseline #... some modifications done rcs ci #... more modifications rcs ci # then someone committed another change to the repository and we want # to merge that change in cvs update # do the manual merge if neccessary rcs ci # save the merged version #... more modifications rcs ci # OK, let's suppose that our changes are finally complete, and nobody # else has committed any other changes in between cvs ci So pretty much all I want is to make this procedure a bit more convenient, able to handle whole subdirectories as opposed to separate files. As a model consider this: suppose we build a separate copy of the CVS binary, called "mycvs" that has the following differences from the normal CVS: 1. Instead of the variable CVSROOT it uses MYCVSROOT 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS 3. It never touches any of the keywords (such as $Id etc.) 4. When asked to add a file, it automatically creates the whole path of intermediate directories for it. (How does it know where the checked-out tree starts ? There are many more or less obvious and convenient ways to do that, so let's leave this issue alone for now). Then in the example above you can do export MYCVSROOT=~/tmp/cvsroot mycvs init And do everyhing as in the previous example, only replacing rcs with mycvs (and obviously you wold need to do "mycvs add" before the fiest "mycvs ci"). > of verbatim copying of the repository. > > Incoherent: > > ,-------. ,-------. > | Main |---- cvsup --->| Cache | > | Repo | | Repo | > `-------' `-------' > ^ | > | cvs co > cvs ci | > | V > | ,-------. > | | Work | > `-------------------| Copy | > `-------' Why is it incoherent ? CVS checks that the version obtained by "cvs co" and then modified is still the top of the tree. If it's not, it will refuse to commit and will request you to do an update. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E765359.7FC6C541>