[PATCH] convert with clonebranches and splicemap fails

[Peter Rebholz]

On Wed, May 11, 2011 at 2:56 AM, Patrick Mézard <pmezard at gmail.com> wrote:

> Please keep the list in copy.
>
> Yes, that's the idea.
>
> What looked wrong to me is the hg sink already has code to pull from
> siblings when parent branches are missing, and the code did not seem
> especially wrong to me. Also, I have to say I am not really interested in
> the "clonebranches" feature which I consider more than a hack than a
> reasonable feature. It is much more efficient to convert into a single tree
> then loop over the available branches and clone/pull individual branches
> with a post conversion script.


 I understand your frustration with the clone branches feature. However, I
don't think I am wrong in assuming that it is a desirable feature. Branches
as clones is a valid branching model and, since some third party products
like Kiln prefer this model, I have to believe that a number of people are
interested in converting their old repositories in such a fashion. If you
convert with named branches on then it is fairly easy to split that
repository into several clones, but it may not be _obvious_ to a relative
new comer. Furthermore, if you don't convert with named branches (I feel
like most people trying to use clone branches don't want named branches) it
becomes a manual process to determine which head is which branch. Lastly, if
some of the branches have been merged back you won't have a head, making it
harder to find.

Perhaps it would make more sense for clone branches to perform a normal
conversion and then split it out at the end as you suggested could be done
with a post conversion script. At least the conversion process has the
knowledge of where in the source repository converted revisions came from.
That said, is this much different than what would happen if source revisions
were properly sorted (as we have been discussing)?

Thank you again for your time,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110511/65c70a7d/attachment.htm>