monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Request for help adding monotone output to cvs2svn


From: Bruce Stephens
Subject: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Date: Tue, 18 Sep 2007 12:48:49 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Markus Schiltknecht <address@hidden> writes:

[...]

> Right. For every tag and branchpoint which cannot be matched to
> exactly only one revision, you'll have to add an artificial revisions
> which you can tag. (AFAICT, git allows such an artificial revision to
> have multiple parents, monotone does only allow two parentsn. So for
> monotone, you'll have to add multiple artificial revisions).

I don't think monotone has such a restriction.  I think it happens not
to create such revisions at present, but I don't think there's any
intrinsic requirement that a revision has at most two parents.  I
imagine an importer from cvs2svn would use "automate put_revision" or
something, and I suspect that'll be happy with any number of parent
revisions.

> For branchpoints, it's quite clear that such artificial revisions for
> those can go into the branch they initiate. But for tags, you'll
> probably have to create an 'artificial' branch, or not assign any
> branch cert to those revisions.

Yes, I think the former. I think it would be natural to have them on a
branch, maybe one named relative to the tag name.  (Or identical to
the tag name, as you did with git.)

>> (In git it's normal for a branch to contain divergence in its past,
>
> Uh.. what do you mean by that?

I mean the graph of a branch may not be linear, but will (by
definition) only have one head.  Such a thing will be the result of a
merge, and at that point the two (or more) things being merged would
normally be distinct branches.  In monotone it's normal just to let a
branch fork for short periods, but in git that doesn't really make
sense---each of the forks is a separate branch.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]