feature request: replicate stripping of revisions

[Dustin Sallings]

   Note that clone -r doesn't delete history, it only creates a new  
copy of a repo that doesn't include part of it.  The original repo is  
not modified, and the new one just has the history up to that point  
appended to it.

   For my uses, appended-only means a clone plus a periodic pull means  
I will always be able to reproduce any revision throughout history.   
That is my backup startegy.

-- 
Dustin Sallings (mobile)

On Dec 2, 2007, at 12:15, "Georg-W. Koltermann"  
<gwk.rko at googlemail.com> wrote:

>
> Am Freitag, den 30.11.2007, 16:17 -0600 schrieb Matt Mackall:
>> ...
>>
>> Strip is not a core command, it's part of mq. And that's because it
>> breaks one of our basic rules: history is append-only. Breaking that
>> rule is ok for private development repos, but risky for more public
>> ones.
>>
>
> I don't see how that solves the problem.
>
> I agree that treating history as append only is a valid and useful
> principle.  But even core Hg isn't always strict with that.  If you  
> "hg
> clone -r xxx", you also leave behind part of history, don't you?
>
> Do you have a better suggestion?  Could one hide obsolete parts of
> history?
>
> SVN for example shows relevant tags and branches in a directory tree.
> You can reorganize the tree or delete parts of it.  That won't throw
> away history, it only alters the view you get by looking at the tree
> through the head revision.
>
> In Hg, could there be a similar feature, just show tags, branches and
> heads through a kind of view or filter that changes over time, and  
> hide
> obsolete parts?  Older views of branches/tags/heads would be  
> accessible
> when looking through a historic version of the view.
>
> Just an idea, maybe I'm biased by having the SVN example, maybe there
> are better ways.
>
> --
> Regards,
> Georg.
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>