On Tue, Apr 17, 2001 at 12:49:17PM -0500, Karl Fogel wrote:
> Jason Molenda <jason-svn@molenda.com> writes:
> > 2001-04-10T08:15:10 bob A/f,1.3 B/e,1.8 C/d,1.4 D/c,1.18
> > 2001-04-10T08:35:25 susan C/d,1.3
> It's quite detectable. If cvs2svn's "call-it-a-commit window" is
> greater than 45 seconds wide, then Bob's change to C is still part of
> his commit. It doesn't matter that Susan got one in before him.
>
> It's not horrible if cvs2svn can't always order two commits that
> happened simultaneously and affected some of the same things. It will
> just have to arbitrarily put one before the other.
My concern is that susan's change to C/d could conflict with bob's
change to C/d, and cvs2svn would try to apply them in the wrong
order (because his overall operation started first). For a correct
import, susan's change must be applied before bob's, but bob's
_overall_ cvs operation started before susan's so cvs2svn will have
trouble figuring that out.
You can even come up with a pathological bad case like
2001-04-10T08:15:10 bob A/f,1.3 B/e,1.8 C/d,1.4 D/c,1.18
2001-04-10T08:35:25 susan A/f,1.4 C/d,1.3
where bob's checkin to A/f finishes, his checkin to B/e is happening,
and susan swoops in and checks in A/f and C/d. In this case, there's
no order where you can guarantee that the import will work cleanly if
you import them as grouped changesets.
My original example was unlikely. This second example is vastly
less likely to show up in real life. But I thought I'd raise it
as long as I was here. :-)
Well, if nothing else, cvs2svn would see that (in example 1) bob's
delta doesn't cleanly apply to C/d and could raise and exception
to the user in this case. I'm not sure it could recover and continue
to do most of an import, though; it might have to bail on the whole
cvs2svn import and ask for guidance. (I could be wrong, I haven't
thought about it much yet.)
Jason
Received on Sat Oct 21 14:36:28 2006