Date: Mon, 17 Mar 2003 20:12:58 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Nate Williams <nate@yogotech.com>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <3E769CCA.7E9BD340@mindspring.com> References: <3E73DCF7.80490FA6@bellatlantic.net> <15988.49648.483313.383942@emerger.yogotech.com> <3E74CC37.DF83EE46@bellatlantic.net> <3E750471.3498C9BE@mindspring.com> <3E765359.7FC6C541@bellatlantic.net>
index | next in thread | previous in thread | raw e-mail
Sergey Babkin wrote:
> Terry Lambert wrote:
> > 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:
[ ... ]
> # OK, let's suppose that our changes are finally complete, and nobody
> # else has committed any other changes in between
> cvs ci
Suppose someone has? If you are so out of touch with the net you
need a cache, you are probably going to get a conflict, because
people are tweaking things all the time, sometimes, it seems,
rearranging the deck chairs to get their name in CVS lights. 8-).
> 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.
That's reasonable, but... you're rcs ci is a killer; it assumes
a local repostory in parallel. I guess you want a "multicvs",
which does checkins remotely or locally?
If you want all of your checkins checked in, then you could do
this with a shell script wrapper that knew about "link up" on
your network interfaces. Is that a possible solution for you?
> 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").
That's actually grosser than the rcs version (IMO)...
> > of verbatim copying of the repository.
> >
> > Incoherent:
[ ... diagram ... ]
> 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.
I left out the (I thought) obvious part; ket me fix it:
,-------.-----cvsup(1)->,-------.
| Main |---- cvsup(2)->| Cache |<------.
| Repo | [CONFLICT] | Repo | |
`-------' `-------' |
^ | |
| cvs co |
cvs ci(2) | cvs ci(1)
[CONFLICT] V |
cvs ci(3) ,-------. |
| | Work | |
`-------------------| Copy |-------'
`-------'
Order:
cvsup(1)
cvs co
cvs ci(1)
cvs ci(2) [CONFLICT]
[FIX] cvs ci(3)
cvsup(2) [CONFLICT]
In other words, you can't order commits with conflicts, without
going to the main repo first in call cases. That destroys your
intended disconnected use.
The first time you get a conflict, your MYCVSROOT repository
is blown, and you won't be able to resyncronize it, without
replacing ",v" and "CVS/*" file contents.
In other words, any time, there is a "checkin to main repository"
conflict, your foot goes "bye bye"...
Make sense?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E769CCA.7E9BD340>