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

[Samium Gromoff]

At Sun, 28 Sep 2003 12:12:49 +0200,
Andrea Arcangeli wrote:

[snip]

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

        Andrea, note that this is only true if _every_ instance of the
 old type FS`s in use is replaced by reiser4, xfs, whatever.

> > 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/

regards, Samium Gromoff