Patrick Georgi <[EMAIL PROTECTED]> writes:
> Bruce Stephens schrieb:
[...]
>> For that matter, I guess it might be feasible to read git's
>> fast-import format instead (that would probably take a bit more
>> effort, but might be more useful).
> I started such an effort, but considered it not wo
Bruce Stephens schrieb:
> cared about this could hack a monotone backend in a day or two;
> maybe longer if it turned out that monotone needed extra automate
> features, but I'd guess it wouldn't now that there's a way to
> commit revisions.
automate is definitely enough for hg2mtn...
> For that m
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
[...]
> Maybe cvs2svn is coming closer to being able to export to monotone.
I don't think there's any question. There's (experimental,
admittedly) code to export to git, and it's ~500 lines of Python.
git is more or less equivalent to monotone in
Hi,
Nathaniel Smith wrote:
Or just pick whichever single parent is the closest match, and write
out the tag as a child of that.
That would mean adding an artificial patch (from that closest match to
the tag revision you need) and an artificial revision (the one which you
are tagging). To m
On Tue, Sep 18, 2007 at 12:44:06PM +0200, Markus Schiltknecht wrote:
> 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 p
Hi Bruce,
Bruce Stephens wrote:
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_rev
Patrick Georgi <[EMAIL PROTECTED]> writes:
[...]
> There are a couple of invariants in the code that require revisions
> to only have to ancestors. And I think some of the routines are
> hardcoded for "either one or two ancestors", too.
OK, I was misremembering.
___
Bruce Stephens schrieb:
> 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_revisi
Markus Schiltknecht <[EMAIL PROTECTED]> 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
Hi,
Bruce Stephens wrote:
OK, that's probably worth doing. For repositories which include
imports, I suspect many of the tags will require a branch. I guess it
would depend on how one uses CVS tags as to whether it's often the
case that a branch is unnecessary. (At work we quite often (more
o
Michael Haggerty <[EMAIL PROTECTED]> writes:
[...]
> cvs2svn added the unnecessary branch names because of a bug in
> git-fast-import. I think that problem is fixed, but I haven't gotten
> around to changing cvs2svn.
Ah, OK.
> More interesting is whether the branches have to be created at all
Bruce Stephens wrote:
> Michael Haggerty <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> (I've already made this offer [to cooperate in adding mtn support to
>> cvs2svn] to Markus Schiltknecht but he doesn't seem interested.)
>
> I suspect because cvs2svn isn't incremental. So it's a way to do a
> o
Michael Haggerty <[EMAIL PROTECTED]> writes:
[...]
> (I've already made this offer [to cooperate in adding mtn support to
> cvs2svn] to Markus Schiltknecht but he doesn't seem interested.)
I suspect because cvs2svn isn't incremental. So it's a way to do a
one-time conversion of a CVS repository
13 matches
Mail list logo
