Re: [Gnu-arch-users] Re: DARCS

[Mirian Crzig Lennox]

address@hidden (Tom Lord) writes:
> 
> Given the long history of people living with things like CVS
> directories, and the relative benefits of .arch-id storage of explicit
> tags, complaints about "those extra directories in my tree" seem to me
> to be not very serious.

I would argue that there are some advantages in the ability to store
metadata in a way that does not require modifying the user's source
tree;

    * The user does not need write permission to a directory hierarchy
      in order to import it into revision control.  Even creaky old
      CVS does not require this; I can mount a CD or a read-only
      remote filesystem, and cvs import the contents just like that.
      This ability is actually quite handy.  I haven't figured out a
      good way to do it in Arch without copying the directory
      structure to local storage first.

    * A working source tree can easily be made readable via http, ftp,
      nfs, etc. without exposing metadata.

    * Any ordinary source tarball on the net somewhere is
      automatically a pristine tree.  For large, externally developed
      projects such as Linux, it is only strictly necessary to
      persistently store that subset of files which are actually
      changed locally.

    * For externally maintained projects which are archived locally in
      Arch, it is inappropriate to submit patches containing Arch
      metadata.  Such patches would also fail on the maintainer's tree
      and likely be rejected.

There are a whole category of problems and potential problems that can
be avoided if we take the hardline approach that the content of the
user's source tree is sacrosanct.

In fact, I believe that even now Arch provides a way to achieve this
(at the expense of some features), via the "names" tagging-method.  Is
it correct to assume that Arch will not add nor modify non-source
files below the top-level directory if "names" tagging is used?

cheers,
--Mirian