Jason Molenda <firstname.lastname@example.org> writes:
> I think this will be a tricky problem to solve. Is it worth solving
> from the start? If the goal of collating individual checkins into
> changesets is ignored, you get a subversion repository with lots
> of one-file changes after the cvs2svn conversion, but it'll be a
> lot easier to write cvs2svn. That doesn't seem so bad.
> In an attempt to collect individual cvs checkins into groupings,
> we paper over the fact that cvs doesn't have atomic checkins, and
> eventually cvs2svn will lose because of that.
You're absolutely right, of course --- atomic checkins don't exist in
CVS, so there's no guarantee that cvs2svn will reliably recognize what
users intended to be single checkins, and turn them into single
Subversion revisions. The data simply isn't there.
However, as you point out, it's no tragedy to recognize commits
inaccurately, as long as the contents and echronology are correct.
Even if we just toss all questionable cases, we're still doing better
You do mention something that hadn't occurred to me: we must make sure
we don't process any revision from an RCS file before we've processed
all its ancestors. If cvs2svn stored a property on each file in the
Subversion repository indicating which RCS file and revision it came
from, we could check this.
Received on Sat Oct 21 14:36:28 2006