Re: [Gnu-arch-users] arch lkml

[Bruce Stephens]

Tom Lord <address@hidden> writes:

>     > From: Bruce Stephens <address@hidden>
>
>     > 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.
>
> It's a pretty serious performance issue, I think.

Only when there's lots of renaming going on, it seems.  And that's
rare, so I don't see it as that important.  (It may be that it's rare
because CVS, patch, etc., don't support it well (or at all).  I think
it'll always be relatively rare.)

>     > > 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.
>
> Related to that conflict: what happens when two branches both add
> logically distinct but same-location files -- then I try to merge
> from both branches?

What happens now?  Several things seem possible.  For example, Arch
could rename both, giving them distinct names.

> I take back what I said: something like what you've proposed (trying
> to use relative paths as file tags) simply can not work.

Perhaps not, and it doesn't matter much (even if it could work, it'll
be more complex, so your choice of taglines makes much more sense).  

I still don't see where the idea breaks down, though.  I'm *not*
proposing using relative paths as file tags; I'm suggesting using
relative paths, encoded in the files as $ArchId: tla/libarch/...$ or
whatever, as file tags for a specific working tree.  They're temporary
and local.  When you commit, you'd remove the tags (leaving just the
marker $ArchId$).  

So almost certainly, you'd somewhere record permanent tags for files.
So in the example above, the two branches would have the same named
file, and so in a working tree of either, those files would have the
same $ArchId$ tag, but in the archives they'd be distinct, having been
given a uuid or something for their permanent tag.  So Arch would know
that they were different, when it came to merging them---the only
issue is how to present that information.

In practical terms it doesn't matter---tla is now nice and fast, and
this would slow it down, quite possibly unacceptably.  If the
performance issues turned out to be not so bad, though, it feels like
a possibility for some new system.