Sergey Babkin wrote:
> Terry Lambert 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".
How? Your local repository is out of date. You can't update
your local repository because it's a cache, and the cache contains
some local changes, and any update will bow those changes away, or
abort because there's a conflict. This is exactly my "incoherent"
picture.
Are you saying that you can "cvs update" vs. the main repository
the checked out local sources, merge the changes, and do it that
way? If you do that, you lose your locally maintained modification
history.
> > > 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.
You want to save it in a local cache. I get that. The local
cache is "a snapshot of the remote repository, which is out of
date", right? You don't have access to the remote repository
in order to make the local cache "not out of date". So you
commit it to the local cache.
You find you need a fix, make another change, and then commit
*that* to the local cache. Then you want to commit the changes
in the local cache to the remote repository.
Have I understood you so far? If so:
Q1: The original commit comment is some long-winded thing
that explains the reason for the change, and the next
comment is a terse "fix logic error in hash lookup", and
the next comment is a long-winded thing about another
new feature. Do you want to maintain the modification
history for the intermediate local copies?
Q2: If the answer to Q1 is "no", then what the heck happens
to the commit comments for the first several commits?
Q3: If the answer to Q2 is "glue them all together", then do
you maintain a commit per comment, to keep comments like
"fix logic error in hash lookup" meaningful, or do you
just dump meaningless comments into the main repository
later?
> > ,-------.-----cvsup(1)->,-------.
> > | Main |---- cvsup(2)->| Cache |<------.
> > | Repo | [CONFLICT] | Repo | |
> > `-------' `-------' |
> > ^ | |
> > | cvs co |
> > cvs ci(2) | cvs ci(1)
> > [CONFLICT] V |
> > cvs ci(3) ,-------. |
> > | | Work | |
> > `-------------------| Copy |-------'
> > `-------'
[ ... ]
> 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)
BOOM! YOUR HEAD EXPLODES!
cvsup(2) will consider the cache repository HEAD trashed. It will
either abort, or it will overwrite your cache contents, and you
will lose your local modifications. Either way, you are screwed.
You can't make local checkins to the same place CVSup writes to.
> > 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.
That's not there in this diagram. I tried to give you a second
diagram, which I labelled "coherent", which had a second, seperate
local repository, but you guys rejected it.
You can't make local checkins to the same place CVSup writes to;
CVS is too stupid, and CVSup is too stupid to handle it. You'd
need a "multicvs" -- one that could operate a shadow repository.
I still think the best idea is to start a snapshot, and make
your local checkins there. That leaves the non-snapshot CVSROOT
from the CVSup unchanged, and gives you a base from which you
can recover local changes.
When everything is done being checked into the remote repository,
then you simply delete the snapshot.
In case this was unclear, I'm suggesting using the FFS feature
called "snapshots".
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
