gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] 'arch send' format


From: Paul Mundt
Subject: Re: [Gnu-arch-users] 'arch send' format
Date: Fri, 16 Apr 2004 18:02:20 -0400
User-agent: Mutt/1.5.6i

On Fri, Apr 16, 2004 at 01:22:48PM +1000, Martin Pool wrote:
> For example, here's an explanation by tytso of how to send him changes
> over email:
> 
>   http://e2fsprogs.sourceforge.net/e2fsprogs-hacking.html
> 
> And here is an example of the output:
> 
>   http://lwn.net/Articles/32520/

Not quite. This is an example of bk export -tpatch -du -rrev. Using plain-text
exports such as this won't retain metadata in BK, it will reproduce the change
when you bk import. (ie. if you clone from linus, make some changes, send the
plain-text patch, and he merges it, then later if you pull into your tree again
you'll have a merge point + another cset rev including the same change that you
already have in your tree. BK will also generate a nice conflict on this that
automerge for some reason has issues with, which in itself is a bit annoying,
since there's no real changes -- this itself has caused me a lot of grief, since
if you opt to use the local file over the remote one it will silently drop all
future external changes to that file unless you manually move out the file from
the deleted list, which was non-obvious until Larry pointed it out ;-)

bk send / receive on the other hand operate on BK patches, which are uuencoded,
generaly not human readable, and generally include things like useless merge
points for ancestry tracking (this gets very tedious with things like the
kernel, where after you've been doing work for awhile and pulling from other
trees, you end up with dozens of merge points all of which need to be roughly
included in the bk patch in order to preserve history -- plain-text exports are
much easier to deal with). It's very tedious to do the equivalent of a replay
to drag in a single cset between trees and maintain metadata when you have
anything other then a small handful of merge points.

Either way, the concept itself is nice. I'd certainly make use of such a
feature.

Attachment: pgpWhoVfVKMAb.pgp
Description: PGP signature


reply via email to

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