monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Commit a child of 2 parents


From: Yury Polyanskiy
Subject: Re: [Monotone-devel] Commit a child of 2 parents
Date: Sun, 15 Jan 2006 21:21:27 -0500

Oh, ok. I knew I was missing something obvious. Sorry for not RTFMing
enough.

I'm not talking about a quick hack but rather a complete lossless
converter from BK to monotone. The way to do this is to either integrate
infamous SourcePuller (by A.Tridgell) inside monotone. However that
would probably invoke a lot of fuss from BK people. 

The other way is to hack SP and make it call regular monotone commands.
In this latter case, of course it'd be nice if the tool worked with
standard monotone releases, not some specially patched ones. So I'm
just looking for a way to do this.

Again thanks everyone!

Yury.


On Sun, 2006-01-15 at 17:29 -0800, Nathaniel Smith wrote:
> Because edges are not stored separately from revs.  A rev contains a
> list of its parents in its text; a revid is the hash of that text.  So
> adding a new parent would require actually going and modifying the
> existing rev's text, and thus changing its id, which invalidates
> existing certs, etc.
> 
> The "concepts" chapter of the manual hopefully covers this sort of
> thing:
>   http://www.venge.net/monotone/docs/Concepts.html
> If anything's unclear then we'd love to hear :-).
> 
> Doing all these adjustments by hand while maintaining data consistency
> would be very tricky.  You basically end up duplicating big pieces of
> monotone's own code.
> 
> Doing it from _inside_ the monotone code is less problematic; we can
> generate whatever revs we want pretty straightforwardly.  If you
> really want an expeditious hack, you're probably best off figuring out
> some way to hack some sort of special purpose command into monotone.
> 
> What system are you coming from, again?  There is some code already
> to do lossless imports from git repositories (which is starting to
> rot, but we should fix that)); adding code to do the same from other
> VCSes is probably a bit more work than writing a quick hack in shell
> or whatever, but could also be quite valuable.
> 
> -- Nathaniel
> 




reply via email to

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