Subject: Re: Tagline tagging failings -- Was: Re: [Gnu-arch-users] tla mv
	gets me an error next commit
From: Charles Duffy <cduffy@spamcop.net>
To: "Karl O. Pinc" <kop@meme.com>
In-Reply-To: <20041115221021.Y16278@mofo.meme.com>
References: <20041115151313.I8700@mofo.meme.com>
	<41995266.6060400@arbash-meinel.com>
	<20041115195312.I16278@mofo.meme.com>
	<buod5yeef5n.fsf@mctpc71.ucom.lsi.nec.co.jp>
	<20041115201538.O16278@mofo.meme.com>
	<buopt2ecz9b.fsf@mctpc71.ucom.lsi.nec.co.jp>
	<20041115205438.U16278@mofo.meme.com>
	<buois86cwx9.fsf@mctpc71.ucom.lsi.nec.co.jp>
	<20041115221021.Y16278@mofo.meme.com>
Date: Mon, 15 Nov 2004 22:13:05 -0600
Message-Id: <1100578385.15201.149.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org, Miles Bader <miles@gnu.org>
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: 1878
Lines: 50
On Mon, 2004-11-15 at 22:10 -0600, Karl O. Pinc wrote:
> Explicit tags serve exactly the same _function_ as taglines, but they
> are a _different_ 'recordkeeping' implimentation.  And my point is that
> they are not interchangeable.  In some cases explicit tags are required.
> So, why not make other sort of in-tree recordkeeping required to
> support some functionality?

Karl, let me restate Miles's point:

Explicit tags still can be manipulated without tla add/rm/mv. They
couldn't be used to assist partial commits without losing this property.
It's a good property to have, and an implementation that didn't keep it
as a constraint would be quite a bit more fragile.

> And the advantage of taglines is that you can use any tool to
> manipulate the tree.

No, you can do that with explicit tags too, as long as you observe the
documented interface and modify the external tagline in .arch-ids/ as
well.

>   But in those cases when you still need
> explicit tagging you're stuck and limited to using the
> revision control tools.  

Wrong, for the reasons given above.

> You seemd to turn to arguing against any sort of
> in-tree recordkeeping,  Which struck me as impossible, and
> I could not resist saying so.

He's arguing against transactional recordkeeeping -- storing information
in the tree about how to get from its initial (as-checked-out) state to
its current (as-modified-pre-commit) state, rather than just storing
information in the tree about what its current state is.


I'm sorry not to have ended the thread where you wanted to end it -- but
it seemed to me that there were perhaps some rather substantial
misconceptions unresolved.


_______________________________________________
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/