Terry Lambert wrote:
>
> Sergey Babkin wrote:
> > # 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
It's very likely that the conflict can be cured by a simple
"cvs update".
> > 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?
I'm not sure what is a "multicvs", I just want to have some
storage for the data before I get to commit it to the real
repository. For example, suppose I write some code. Then I run
a test on it and find some deficency that needs a non-obvious
fix. At this point I want to save the present version somewhere
before I start doing the fix, to make sure that I at least
won't make things worse, and if I make them worse then I can
always return back. After the fix is done and the test
runs successfully, the final result can be committed to the
central repository.
> > 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:
>
> That's actually grosser than the rcs version (IMO)...
It's only an example to show an analogy. Though after thinking
about it, it looks like a good model to start with and cover
under the hood of cvs commands.
> > > 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.
When cvs ci(2) finds a conflict, the master repository is left
unchanged. So cvsup will never see any conflicts. The real sequence
would be
cvsup(1)
cvs co
cvs ci(1)
cvs ci(2) [CONFLICT - check-in fails]
cvsup(2)
cvs update
[hopefully update resolves the conflict, or fix it manually]
cvs ci(3)
> 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.
No. Two repositories in this example are completely independent.
Their only connection is by checking in and out the same file
manually.
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
