[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mercurial
Subject:    Re: feature request: replicate stripping of revisions
From:       Matt Mackall <mpm () selenic ! com>
Date:       2007-11-30 22:17:52
Message-ID: 20071130221752.GS19691 () waste ! org
[Download RAW message or body]

On Fri, Nov 30, 2007 at 05:07:49PM +0100, Georg wrote:
> This is a request for a feature useful in a star-collaboration workflow.
> 
> Consider you have an "authoritative" shared team repository where all team
> members can push.  This is a little like the Mercurial crew repository.
> 
> As time goes on, team members push their changes to the repository for
> review by others and integration.  Some contributions get integrated, some
> don't.
> 
> So those that don't get integrated stay behind as garbage and accumulate
> over time.
> 
> Every once in a time you may want to purge the shared repository of the
> garbage.  Technically no problem, you can use hg strip or hg clone -r.
> 
> BUT, you really don't have only one copy to purge.  Every team member has
> her/his own copy, quite possibly several of them.  As soon as anyone pushes
> back to the team repository, it will push in the garbage again :-(
> 
> Yes, you can instruct team members to discard all their copies and do a
> fresh pull.  It's inconvenient. It's error prone, at least one repository
> will remain unpurged (Murphys law).
> 
> Yes, you can instruct team member to /never ever/ do a plain push, but only
> push -r instead.  So they don't carelessly push old stuff, they only push
> their particular change.  This has two drawbacks. First, the team member's
> repository will still contain the garbage locally, second every once in a
> while someone will do a full push w/o -r.  Murphys law.
> 
> 
> What I thought might help is a feature for replicating stripping.  You would
> strip the garbage in the shared repository.  As soon as team members pulled
> from the shared, they would "pull the stripping", the same stripping would
> be applied at their local clone.
> 
> If this looks too dangerous, then what do you think about keeping and
> replicating a list of "obsoleted" versions, and having a manual command like
> "apply obsoletes".  That command would read the list of obsoleted versions,
> and if any of them still exist locally, it would hg strip it.

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.

-- 
Mathematics is the supreme nostalgia of our time.
_______________________________________________
Mercurial mailing list
Mercurial@selenic.com
http://selenic.com/mailman/listinfo/mercurial
[prev in list] [next in list] [prev in thread] [next in thread]