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

[Davide Libenzi]

On Sun, 5 Oct 2003, Miles Bader wrote:

> On Sun, Oct 05, 2003 at 11:02:46AM -0700, Davide Libenzi wrote:
> > 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.
>
> Complaints about `add' are pretty common with CVS (`move' not so, because CVS
> doesn't support it :-).  The conversation often goes like this:
>
>   `Hey your new changes don't even compile!'
>
>   `What?!? I tested them massively... hold on ... grumble ...mumble ...
>    Oh.  (pause)
>    Um, please do a cvs update, and try again.'

I worked (and I currently do) with CVS for many years, even with new hired
that are fresh to SCM concepts. If the above scenario happens once every
two months is a lot. And the solution is far from difficult. I'll ask you
a question though. Why no one of production/commercial SCM ever
implemented the magic recognition feature ? Even new bleeding edge products
like BK. You know that those marketing folks go deep digging for new
features to justify new release to have customers to pay for updates.



> > The tagging concept should/must be completely *transparent* to the
> > user, to the point that he does not even know of their existance.
>
> And yet you go on to suggest a method that's far from transparent.
> Taglines are if anything _more_ transparent than what you suggest.

Transparent here mean: The user does not have to have a clue of what a tag
is, and the SCM *must* be able to do the right thing w/out requiring him
to add stuff in his data. And, BTW, binary files are hard to tagline, and
this makes the method asymmetric from an implementation point of view.



> [But no mechanism can ever be really transparent, except perhaps for `names'
> with _every_ file considered as source (backups, objects, you name it)]
>
> > SCM *must* be able to do the right thing w/out the user having to even
> > think about tagging and whatever a tag is.
>
> Why?  There's no `must.'  Taglines are not perfect, but it's a _tradeoff_.
> They give recognizable advantages over `traditional' mechanisms, but they
> introduce a new concept (a rather simple new concept, but none-the-less).
> The state of the art _does_ occasionally advance, you know, and sometimes
> it's even a good thing.

Because it is simpler for the SCM is the rule is: Every file that enter
the system must have a tag inside its metadata. Again, it has never been a
problem for end users to add/mov/del from their repository. Really,
otherwise the would have implemented it. No rocket science involved here.
With an always-present and auto-generated tag inside the metadata, the SCM
is able to describe/map all operations farily easily.



> For a big project like linux, learning this new concept is very, _very_
> small price to pay.
>
> I realize you hate the idea of `metadata' polluting your files.  But you
> know, if Linus were to add taglines to the kernel, I'll bet that after the
> initial massive shock to your sense of cleanliness, you wouldn't even notice
> them -- they're simply not very intrusive in reality.  [I can say this
> because I've actually used them, on a multi-developer project, where most
> people are entirely clueless about arch.]

I can't talk for Linus, but he didn't have a single complain about him
having to do 'bk add'. Did you hear something ? I didn't. Operations like
add/mov/del have a so little frequency that it is really a non issue for
the user. I do not believe it is the time to try a push of Arch to lkml
yet though. There's the risk to burn it w/out a plan that maps common
Linus/big-maintainer usage pattern to Arch/derivated-tools operations.




- Davide