Date: Tue, 8 Feb 2005 23:12:51 +0000
From: Mikhael Goikhman <migo@homemail.com>
To: Aaron Bentley <abentley@panoramicfeedback.com>
Subject: Re: [Gnu-arch-users] Re: Making --setup default in tag and import
Message-ID: <20050208231251.GA1604@ukato>
Mail-Followup-To: Aaron Bentley <abentley@panoramicfeedback.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>, gnu-arch-users@gnu.org
References: <20050207184626.GB11858@ukato> <200502071913.LAA09656@emf.net>
	<87sm47i0d1.fsf-monnier+gmane.comp.version-control.arch.user@gnu.org>
	<4208DE97.40706@panoramicfeedback.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4208DE97.40706@panoramicfeedback.com>
User-Agent: Mutt/1.4.2.1i
Cc: gnu-arch-users@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 1828
Lines: 42
On 08 Feb 2005 10:45:27 -0500, Aaron Bentley wrote:
> 
> Stefan Monnier wrote:
> >>There can not be an officially supported "undo in the archive" operation.
> >>That's an absolute constraint.  Sorry.
> >
> >Too bad.  It's not like it's fundamentally impossible/difficult.
> 
> Actually, it *is* fundamentally impossible.  The arch model is that each 
> revision name corresponds with one and only one changeset or import. 
> Forever and ever.  Break that rule, and you get to keep both pieces.

These two requirements do not really conflict in any fundamental way.
You may redo the past if you also redo or remove all its dependencies.
There are several solutions here with a different set of consequences.

One naive (and inconvenient) solution is to only allow getting revision
in one hour from its creation and give time to the creator to replace it.

A better solution is to use timestamps of archive revisions and invalidate
any trees or secondary branches that depend on the revisions with older
timestamps. Note, that invalidation is what a user intends when he undoes.
He does not intend for the previous (replaced) changeset to be ever valid.

One easier-to-implement solution (the one I suggested) is to only make
cache and mirror processes aware of the archive changes by revalidating
stored data, either on request or just all recently created data, and not
to perform any automatical invalidation. The user is then responsible to
invalidate (remove) any affected trees or revisions if any. If he worries
about external trees or branches, then he should not undo in the archive.

Regards,
Mikhael.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/