[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] arch lkml
From: |
Bruce Stephens |
Subject: |
Re: [Gnu-arch-users] arch lkml |
Date: |
Thu, 11 Dec 2003 17:43:09 +0000 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> writes:
[...]
> _Maybe_ something like that could be worked out but I think it'd be
> hard.
>
> Consider, for example, what happens not on `commit' but on, say,
> `update' where the changes brought in by update have renamed a
> top-level directory. The id strings in all the files below that
> would have to be updated.
That's annoying, but I don't see a logical problem.
> To make matters worse, if the update contradicts a local change (by
> trying to put to files at the same relative location) what are you
> going to do then with these ids?
That's a conflict, so there's no right thing to do---nothing that you
can do without getting the programmer to resolve the situation. I'd
guess there are several ways of recording the problem; I'm not sure
which would be most convenient.
> Of course, if the "whatever else seems useful" includes an ordinary
> arch tag these problems disappear -- but in that case you aren't
> really using the relative path names for anything.
If you like, you could imagine a file containing the mapping between
arch-tag and thing in $ArchId$ being kept in {arch}. Then all that
update, etc., have to do is maintain that mapping, and they can use
the same logic they currently do in the case of conflicts. So as far
as I can see this is no less powerful than arch tags---it's just more
complex. (I may be wrong, though---I haven't thought carefully enough
about this.)
Some advantages: people who've used CVS or SCCS would be comfortable
with these strings, and they wouldn't edit them; the expansion could
contain more than just the relative filename, it could contain times,
branches, etc. (The extra stuff wouldn't be used by Arch, but it
might be convenient for users.)
- Re: [Gnu-arch-users] arch lkml, (continued)
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/13
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/13
- [Gnu-arch-users] Considering Semantics with a simple but stupid file archive format., Eric W. Biederman, 2003/12/13
- [Gnu-arch-users] Re: arch lkml, Miles Bader, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Aaron Bentley, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Mark A. Flacy, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/11
- Re: [Gnu-arch-users] arch lkml,
Bruce Stephens <=
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Andrew Suffield, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Karel Gardas, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Karel Gardas, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/11