Re: [Gnu-arch-users] arch lkml

[Bruce Stephens]

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.)