Bazaar as a working interface to Darcs repositories

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Finney wrote:
> Jelmer Vernooij <jelmer at vernstok.nl> writes:
> 
>> There is a fast-export frontend for darcs that should allow you to
>> convert from Darcs into Bazaar (and back?).
>>
>> Tailor allows you to do bi-directional conversions of revisions
>> between Bazaar and Darcs.
> 
> They both sound like one-way operations. How would I use these options
> for ongoing collaborate with an active Darcs repository?
> 

essentially diff + patch, unfortunately.

AIUI we could track a darcs repository losslessly about 75% of the time,
until darcs decides it needs to reorder the patches. At that point, the
history conversion will break.

The 'safe' break is to map each darcs revision to 'ancestry(rev)'. Which
means that when darcs reorders, we start thinking of all those changes
as completely new ancestry.

To spell it out as I understand it.

If I'm a developer using darcs, I can commit a series of patches:

 A B C D E F

As someone tracking my work, you can chose how many of those patches you
want to accept, as long as they don't "textually depend" on eachother.
So you can clone from me, but end up with a branch that only has

 A B C F

Thus if I was trying to do a conversion into Bazaar, I can't simply map
 A => A'
 B => B'
 C => C'
 D => D'
 E => E'
 F => F'

because if I did, then branch one would say its last revision was F (and
the corresponding bzr branch would say F'), but the *second* branch
would make the same claim. So instead, bzr would have to do the mapping:

 A => A'
 A B => B'
 A B C => C'
 A B C D => D'
 A B C D E => E'
 A B C D E F => F'
 A B C F => F*


Even more complex is that darcs (AIUI) is allowed to reorder the patches
if it feels it needs to do get the right merge. So in the above
scenario, someone could merge a patch "G" which is, say, based on C, so
from an ancestry like:

A B C G

merged into

A B C D E F

you end up with

A B C G D E F

or even

A B C D G E F

etc. (It depends on the specifics of their patch theory, which I'll
admit I don't fully understand.)

With this sort of action, you probably could still represent individual
"states" in a converter. I don't know how stable the states are. Is
there histerisis (the current state depends on the route you took to get
to that state) or not?

eg: If I start with "A B C", and then merge the "G" change, and then
merge the "E F" change. Am I at the same final state, as if I merged "E
F" first, and then "G" second.

Put another way, is the set(patches) sufficient to describe the state,
or is the state dependent on the details of the patch ordering.


I honestly don't know how you would represent the ancestry of a darcs
revision. Specifically, I don't believe *darcs* records information such
that you can get back to a specific set() of patches as it existed in
the past, unless you explicitly tagged it.

eg: In bzr, if I make a commit today called revid:john at foobar-1234, if I
do a bunch of work tomorrow, merge some stuff, commmit some stuff, do my
own hacking. I can still revert to the state yesterday with "bzr revert
- -r revid:john at foobar-1234". AIU darcs, you need to know the exact set of
patches that you had in your repository yesterday.
Going back to the simple examples above, it isn't enough to know I was
at "F", I need to know I was at (A B C D E F) and not (A B C F).


So what is the "parent" of (A B C D E F). At commit time, you could
probably figure out that this set was generated from (A B C D E).
However, I don't believe darcs stores this information as meta-info
about "F".



In the end, I think you have to live with a fast-export conversion and
diff + patch. 'darcs' internally works completely differently from all
the other DVCS systems. (Except Arch/tla, which sort of had a similar 'I
am the sum of my patches' system.)

I hope this is slightly helpful rather than just wordy. But your best
bet today is to take snapshots of upstream, and collaborate via
something like diff + patch.


One possibility is the 'combined working tree' that I've used in the
past. Namely you do:

darcs clone $upstream upstream
cd upstream
bzr init .
# setup .bzrignore properly
bzr add
bzr commit -m "Initial snapshot from darcs."

And then from there you can do:

bzr branch upstream my-work
cd my-work
<hack hack, commit commit>
cd ../upstream
darcs update # whatever the command is
bzr commit -m "New snapshot from `date`"
cd ../my-work
bzr merge ../upstream
bzr commit -m "Bring in the latest upstream work"

bzr diff -r submit: > ../my-work-for-upstream.patch
# mail my-work-for-upstream.patch, have them apply it, etc.

*If* you have commit rights to the darcs repo, you can do:

cd upstream
bzr merge ../my-work
darcs commit -m "Bring in the changes from my-work" # as a patch
# (this may be 'darcs record', etc.)
bzr commit -m "merge in changes from my-work" #with metadata


If you wanted to be a little bit smarter, you could probably automate
some of the "darcs update, bzr commit" steps. Such that you could
preserve the commit messages of individual changes, etc. Note that you'd
have to figure out how to represent patch-changing logic into reasonable
'darcs update' commands, and then map that into 'bzr commit' entries.

But you basically use the "current darcs state" and the "current bzr
state" on a single location as the mapping between the two VCS systems.

I've done it. It 'works', though it isn't as nice. If someone merges a
patch from you, it is seen as a separate identical change. Which means
that merging that back into your on-going work may conflict spuriously.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrPTl8ACgkQJdeBCYSNAAMpxACfcBfxB+hPBdVa5chHVNQcfS3i
1NQAn2Zcm/Z6ly43FjtvZWSP2Vd4zEvX
=j6g9
-----END PGP SIGNATURE-----