[Top][All Lists]
[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.)
[...]
- [Gnu-arch-users] Re: DARCS, (continued)
- [Gnu-arch-users] Re: DARCS, Miles Bader, 2003/09/06
- Re: [Gnu-arch-users] Re: DARCS, Bruce Stephens, 2003/09/07
- [Gnu-arch-users] Re: DARCS, Miles Bader, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Bruce Stephens, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Mirian Crzig Lennox, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Damien Elmes, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Ethan Benson, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Bruce Stephens, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Robert Anderson, 2003/09/07
- Re: [Gnu-arch-users] Re: DARCS, Ethan Benson, 2003/09/08
- Re: [Gnu-arch-users] Re: DARCS,
Bruce Stephens <=
- Re: [Gnu-arch-users] Re: DARCS, Robert Anderson, 2003/09/08
- Re: [Gnu-arch-users] Re: DARCS, Bruce Stephens, 2003/09/08
- Re: [Gnu-arch-users] Re: DARCS, Tom Lord, 2003/09/08
- [Gnu-arch-users] Re: DARCS, Miles Bader, 2003/09/08
- [Gnu-arch-users] Re: DARCS, Tom Lord, 2003/09/08
- Re: [Gnu-arch-users] Re: DARCS, Mirian Crzig Lennox, 2003/09/09
- Re: [Gnu-arch-users] Re: DARCS, Tom Lord, 2003/09/09
- [Gnu-arch-users] Re: DARCS, Miles Bader, 2003/09/09
- Re: [Gnu-arch-users] Re: DARCS, Jan Harkes, 2003/09/10
- Re: [Gnu-arch-users] Re: DARCS, Bruce Stephens, 2003/09/10