gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: DARCS


From: Bruce Stephens
Subject: Re: [Gnu-arch-users] Re: DARCS
Date: Mon, 08 Sep 2003 10:00:24 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

Robert Anderson <address@hidden> writes:

> On Sun, 2003-09-07 at 15:38, Bruce Stephens wrote:

[...]

>> I agree, it's mostly the pristine trees that have caught me out.
>> .arch-ids annoy me because they're the wrong way to do explicit tags;
>
> You've made this assertion repeatedly without substantiating it.  What
> is "wrong" about it?
>
> I looked back at prior discussion, and all I found was this:
>
> Me:
>>> What you're proposing - some sort of textual inventory in {arch}, I
>>> guess - would require the implementation to go through and keep
>>> track of all of that movement and all the implications of directory
>>> moves, etc.  Why do that when the filesystem already does that work
>>> for you?
>
> You:
>>Because (while arch is still gaining mindshare) I can't justify adding
>>taglines.  Because (in general) moving files (or moving directories)
>>is unusual enough that I don't mind remembering to tell arch (or
>>OpenCM, or subversion, or meta-cvs, or whatever).
>
> But that's a confused response.  I was not suggesting that you add
> taglines.  I'm asking why add additional "metadata" in {arch} when
> that is just redundant state to be maintained that could become
> corrupted?

It's not redundant: I'm suggesting there ought to be one place where
the mapping between filenames and ids happens, and that place ought to
be one or more files in {arch}, not scattered around in .arch-ids
directories.

And the other tagging methods can build on that, using taglines or the
names of files to generate the inventory.  There's an issue of what to
store in changesets---if you store the whole inventory each time, then
the size of a changeset increases with the number of files in the
project, rather than the number of files changed.  But that's not hard
to fix.

That approach also has the advantage that that's actually how the
information gets used---tla just uses .arch-ids by scanning them all
and constructing a file.  (Either a file or a hash array in memory; I
forget.  Probably Arch used a real file.)

[...]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]