Re: [Gnu-arch-users] Re: give us a hand with arch

[Andrea Arcangeli]

On Sun, Sep 28, 2003 at 08:03:54AM +1000, Robert Collins wrote:
> On Sat, 2003-09-27 at 22:14, Andrea Arcangeli wrote:
> > On Sat, Sep 27, 2003 at 09:38:30PM +1000, Robert Collins wrote:
> 
> > > it has a benefit: you can choose to use taglines in files in the future
> > > with no headaches.
> > 
> > well, I simply don't think it's reasonable to pollute data with
> > metadata. If everybody would do this, the l-k would be already polluted
> > by bitkeeper-tag: 123123123123124 comments in every file and I guess you
> > wouldn't love it, I certainly wouldn't like I wouldn't like to see the
> > arch-tags spreading all over the tree.
> 
> Yes yes yes. I know thats your preference now. I'm offering you a future
> proofing tip from hard-learned experience. tagline will not impact you
> negatively today, and will give you flexability in the future alright?
> 
> There have been plenty of mails about why it's not pollution and so
> forth, but I think one small bit has been skipped over:
> files have a logical identity. swap_state.c is *not* contextless. It
> really is /mm/swap_state.c.

Sorry but I disagree here and that's the very reason the tag-id are
metadata and they're not data, and they provide zero value to the
project in the long run. Today swap_state.c is swap_state.c, tomorrow
swap_state.c could be nvidia.c just because I did `move-tag swap_state.c
nvidia.c`. then it's just worthless to rememeber that was swap_state.c.

Infact if something the tag-id should be a total random id and 'arch'
should costantly audit for possible collisions since math doesn't
guarantee safetly with the tagline (unlike explicit mode that can
guarantee safety with my my-id+sequencenumber algorithm)

The very moment I run 'tag-move swap_state.c nvidia.c' it means I want
to forget where that file came from in the data.  For me the old
swap_state.c doesn't exist anymore, nobody should remind me where
nvidia.c comes from when I read the source, that's pure confusion and
worthless information in the source. That's nvidia.c now, it's a device
driver. 

If I want to know where this file come from, I will ask cvsps (or future
arch strongly needed equivalent command) where that nvidia.c file
originated from, that's the historical metadata that exists only in a
revision control system. That metadata has nothing to do with the actual
future or past data.

Then I can ask the database to 'tla get' an old revision of the
project, when swap_state.c was really still swap_state.c, to see what
changed after I reused that handy swap_state.c code to build a device
driver. And then again arch should not tell me that this swap_state.c is
really a swap_state.c. Maybe swap_state.c was not even a swap_state.c
but years ago it could have been fs/buffers.c so what, it's just
confusing and it has nothing to do with the actual data and it is sure
not guaranteed to have any value years and years later.

Remebering where the data came from is the very single function of a
source control system, it must not be embedded in the data.

If I really want to remeber about where the stuff came from embedded in
the source, it must be my own choice to add a coment saying "this cames
from the old fs/buffer.c" because so people can understand better or
whatever other reason. And in most cases I may not want to do that.

The proof this is metadata, is that if you had any second channel in the
inode where you could store your metadata (some other projects asked for
this feature over time), you would be using it already instead of
polluting the file (IMHO at least ;). That way (with kernel support for
transparently adding metadata to a file) the explicit mode also wouldn't
require you to add-tag/delete-tag/move-tag, and tagline would be totally
obsoleted.

> The arch tags - explicit ones in .arch-ids, and implicit ones in
> comments in the files - allow you to assign the logical identity of
> swap_state.c to it's context wherever it travels.

the .arch-ids are fine, they're not mixed with the data, I'm not looking
at that until I want to look back (that's why I need a source control
system, exactly to look back). It's just the taglines that shouldn't be
there mixed with the data.

Again, it may be fine in a smaller project so you can still avoid to run
add-tag/delete-tag/move-tag, but in something huge I believe they should
be discouraged.

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/