Re: [Monotone-devel] Re: cvs_import failure

[Markus Wanner]

Hello Michael,

Michael Haggerty wrote:
> Unfortunately, there are cases when adding simple revisions to a CVS
> repository can change how cvs2svn groups older revisions into
> changesets.

Thanks for pointing this out and providing a nice example.

> This can happen even if the new revisions are not within
> the time threshold (by default, 5 minutes)

Note that cvs2svn also groups commits together mainly based on matching
author and changelog. In addition, it doesn't group commits which have
timestamps that are more than a certain threshold apart. I didn't yet
implement that condition in nvm.cbr, so that's where this difference in
explication comes from. Michael's main point still holds true for
nvm.cbr as well.

> In this case, cvs2svn will create BRANCH2 before BRANCH1, because that
> is the preferred order for two files (fileB and fileC) requiring only
> one file (fileA) to be added retroactively to a branch.

The ordering might matter more to subversion that in does for monotone.
Consider that branches and dates are just certificates on some given
content (a revision).

However, in the first step, the first resulting revision for branch
BRANCH1 should only include fileA. After the second step, it should
ideally include fileB and fileC as well. So, yes, that would result in
different result revisions.

(But currently doesn't for nvm.cbr, as it doesn't treat files missing
from a branch as deleted, IIRC. It's comes from my DVCS line of
thinking, where a tag or branch always touches all files of a revision).

> Of course CVS also allows the history to be changed retroactively; for
> example, a file can be added to a tag or branch retroactively; the
> revision of a file that is added to a tag or branch (essentially, the
> branch point) can be changed retroactively; revisions can be "obsoleted"
> (deleted without a trace).  And there are also standard hacks that CVS
> users use (e.g., to rename files) which involve renaming *,v files
> within the repository.

Sure.

Refining my definition the other way around: allowed are only commits to
existing branches (i.e. which don't add new RCS symbols).

Adding *new* tags or branches that span *all* files right from the start
shouldn't pose any problem, either. (For someone intending to change to
a DVCS, that limitation holds true anyway - and even makes sense).

Regards

Markus Wanner