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

Essien Ita Essien me at essienitaessien.com
Sun Sep 2 13:29:16 CDT 2007


Mads Kiilerich wrote:
> 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"

exactly the same.

> 
>> 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"

more like:

  hg clone . ../new-foo-repo
  hg rm foo
  hg com -m "foo split out" foo
  cd ../new-foo-repo
  hg mv 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.

Scenario is this. I have  a project with about 250 changesets, with over 
    subfolders which are gently becoming projects of their own right, 
and I want to convert these into a forest with the least number of key 
strokes.

I tried the bash script approach, worked, but i felt it would be cleaner 
as an extension, and some of the ideas i have now, i don't think the 
base script approach would led me down that path too. :)

> 
>> 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...

(virtually bouncing up and down)... yes! yes! yes!... this would work 
beautifully.

> 
>> 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.

ahh... okay.

> 
>> 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?

lemme investigate mq... see if there's something i can pickup from 
there... thnx for the pointer... forgive my over-enthusiasm too :D

cheers,
Essien
> 
> /Mads



More information about the Mercurial-devel mailing list