Changeset/History munging: was Re: [new-extension] hg breakout

[Mads Kiilerich]

Essien Ita Essien wrote, On 09/02/2007 11:30 AM:
> 1. "cut": In this implementation, I totally obliterate any traces of 
> original history when I create the new repository. From the point of 
> view of the old repo... the new repo has been deleted, while from the 
> point of view of the new repo... the old repo _never_ existed.
>   

In what way is that different from:
mv foo ../new-foo-repo
hg com -A -m "foo split out"
cd ../new-foo-repo
hg init .
hg com -A -m "foo split out"

> 2. "copy": Here I blindly carry along the _entire_ history of the parent 
> repository. This can be problematic size-wise, and this is mainly 
> because there is history for files that are not in the new repository 
> that are still being carried around - baggage.
>   

In what way is that different from:
hg clone . ../new-foo-repo
hg rm foo
hg com -m "foo split out" foo
cd ../new-foo-repo
hg rm .
hg revert foo
hg com -A -m "foo split out"

If it is the same: In both cases I think that it is simpler just to type 
the commands - no need to learn new commands in a new extension.

> I'm searching for a better middleground... a higher solution :)
>
> There are two things I'm thinking of.
>
> 1. Go with the cut option, but have a mechanism that shows us that this 
> is actually a child repo of a parent repo, and then have a "continue" 
> changeset feature... 

I would see this as repos with partial history, where the missing 
history can be pulled on demand. That would be a nice feature whenever 
you are working with repos with a small manifest but long history and 
big .hg and don't need all the "baggage". I think it has been discussed 
before...

> so that if the changesets from the parent stopped 
> at changeset X, the child will start from changeset X+1, and a command 
> will allow use to be able to view the combined changesets all the way 
> back to where the child was cut out from the parent, and then backwards 
> from there.
>
> This would allow development to continue on the parent, and the child 
> would be unaffected, but will keep the implementation simple enough.
>   

The numbering of changesets is local to a repo, so there is nothing to 
keep track of there. It is only the hashes that matters, and in the 
graph of changeset the changesets points at their parents hashes, not 
their number.

> 2. The more obvious option, seems to be grabbing only portions of the 
> parent's log that the list _any_ of the files in the child repo as 
> affected. This has the effect of creating a new repo which doesn't think 
> of itself as a child of any other repo, but a stand-alone repo, with its 
> own self contained changsets that can be used just like a regular repo 
> and can be retraced all the way to changeset 0.
>   

There might be something new and useful here. But aint that a one-liner 
with mq?

/Mads