Re: [Gnu-arch-users] Re: taglines vs explicit

[Davide Libenzi]

On Sun, 5 Oct 2003, Stephen J. Turnbull wrote:

> Wrong.  That's the last thing a _manager_ wants.  Managers want the
> constraints, so they can plan the transition rather than having it
> forced on them.  For example, there are two schools of thought on
> tagline ids: make them human readable and make them clearly not for
> human editing.  While both of them have their points, the last thing
> (eg) Linus wants to see is Andrea using strictly explicit, Miles using
> taglines with uuidgen taglines, and Pau using tagline with descriptive
> taglines, which is a distinct possibility if the kernel were to use
> tagline.

See, IMO the whole problem about tagline,explicit,implicit,... is that the
problem should not exist *at all*. I believe that many of the problems
born from the fact that Arch tries to magically determine if something is
inside the repository or not. I heard really many issues with existing SCM
in the past, but not a single one was complaining about the need of
manually doing add/move/remove to manipulate the repository. Not a single
one. The tagging concept should/must be completely *transparent* to the
user, to the point that he does not even know of their existance. And an
SCM *must* be able to do the right thing w/out the user having to even
think about tagging and whatever a tag is. It should be hidden in remote
files inside the SCM's metadata and assigned during the initial "add"
inside the repository. After that, the tag should follow the file
everywhere the file goes (move). Every file inside the repository must
have an associated tag stored inside the metadata's file that stores
file<->tag associations. If we use a Fully Qualified Path Name like :

id--archive:counter:category--branch--version/full-path-from-tree-root

where "counter" is an autoincrement stored inside the archive metadata, we
should be pretty sure that it'll be unique. It can be left as-is or an
SHA1 can be done on it. A 'tla move' will move the file to a new location
by preserving the original tag, obviously. This is easy to implement if
the user follow strict commits patterns (add/mov/del), while it becomes
non-trivial if we want to detect "moves" magically, by looking at the file
system. If I do something like :

$ mv foo.c new-lib/meaw.c
$ emacs new-lib/meaw.c
(change meaw.c)

it becomes difficult for the SCM to determine if it is a:

move(foo.c, new-lib/meaw.c)
diff(new-lib/meaw.c)

or a:

del(foo.c)
add(new-lib/meaw.c)

While if we do:

$ tla move foo.c new-lib/meaw.c
$ emacs new-lib/meaw.c
(change meaw.c)

It is very easy for the SCM to see that foo.c and new-lib/meaw.c share the
same tag. Yes, editing the *data* file and adding a tag comment would have
made the SCM able to do the trick. But, sigh, why the end user should care
about all this? Since many/all new Arch users will come from SCMs where
they're used to add/mov/del, I believe that the default should be to
require add/mov/del from the user, with Arch maintaining the file<->tag
association in its metadata. The tagline should IMHO be an option for
users that 1) don't mind data<->metadata mixtures 2) really like to avoid
the add/mov/del operations. I might be really wrong here, but I believe
that it'll solve some of the incomprehension problems, and it'll make life
easier for Arch to do the right thing upon moves.
Those are *really* my last words about this matter, and I hope that my
objection has been noted Your Honor :)




- Davide