collected vs distributed working copy metadata

[Karl Fogel <kf...@galois.collab.net>]

Since there's recently been some discussion about possible
arrangements of meta-data in the working copy, I'd like to solicit
opinions.

The current design is that each subdirectory of the working copy has
its own "SVN/" (or ".SVN/") subdirectory.  

Some advantages of this scheme:

   1. Subdirectories are detachable -- any working copy subdir is
      itself a fully independent working copy, so you could move it
      somewhere else and it would still work.  

   2. Administrative information and base versions are close by in
      case one needs to examine them by hand (which, if CVS is any
      guide, is probably inevitable).

   3. It's nice to be able to tell, when you cd directly into some
      random subdir of a working copy, that you are in a working
      copy.  The presence of the SVN/ subdir is a very visible flag --
      for example, when your working copy includes subdirectories that
      are *not* under version control, you can easily distinguish them
      from subdirs which are, just by doing `ls'.

Some disadvantages:

   1. `find', `grep', and wildcard globbing get interfered with by the
      SVN/ subdirs, so you have to be extra careful with such things.
      CVS users know from experience that this can be annoying. :-)

   2. It may be a bit harder to implement than just keeping all the
      metadata in one place (presumably in the top of the tree, or in
      a sibling of the top of the tree).  I'm not sure about this,
      though, not having thought as much about implementing
      metadata-in-one-place as I have about per-subdir metada.

I'd like to know what people think about this issue, especially if you
can add some advantages/disadvantages not listed here.  The working
copy library is solidifying, but it's not committed to one way or the
other yet; before we write that code, we should make sure we're not
missing some big point.

So: thoughts?

(Note that this is *not* a question about whether it should be "SVN/"
or ".SVN/" -- that's just an option, svn should handle both.  If one
chooses .SVN/, that alleviates globbing issues somewhat.)

Thanks,
-Karl

Re: collected vs distributed working copy metadata

[Branko Čibej <br...@hermes.si>]

Daniel Stenberg wrote:
> 
> On Wed, 9 Aug 2000, Branko [iso-8859-2] Čibej wrote:
> > 5) Metadata in _one file_ in each directory
> >
> >    pro: subdirs are easily detachable;
> >         exactly as many globbing problems as, e.g., .cvsignore
> >    con: would have to be some sort of filesystem-in-a-file,
> >         not easily examined or modified by hand.
> 
> Also, this will suffer in large directories or when very many users doing
> operations on the same dir since all operations will use (lock) the same
> single file.

Not if it's a proper database, with record locking. And that's
a prerequisite, anyway.

    Brane

-- 
Branko Čibej                 <br...@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

Re: collected vs distributed working copy metadata

[Daniel Stenberg <da...@haxx.se>]

On Wed, 9 Aug 2000, Branko [iso-8859-2] Èibej wrote:

> Here are some of the options as I see them:
> 
> 1) Metadata in subdir of each directory
> 
>    pro: subdirs are easily detachable
>    con: globbing problems, etc.

There are other pros as well that should be taken into account.

Having distributed files mean less likeness of many processes trying to lock
or mess around with the same file or dir at the same time. It means we can
have files for special purposes and let the files remain simple to parse and
to use simple syntaxes. As opposed to keep it all in a single file at least,
as suggested below.

> 2) Metadata only in subdir of top directory
> 
>    pro: no globbing problems, except in top dir;
>         export == checkout + remove metadata dir
>    con: need special tool for detaching subdirs

More cons:

It is hard to find the top directory. Lots of programs will have to do lots
of directory scannings.

It will also give some kind of problem when the amount of sub-directories
grow. Or should there be a mirrored tree of directories inside that dir?
There will be a need for very many files that need names...

> 5) Metadata in _one file_ in each directory
> 
>    pro: subdirs are easily detachable;
>         exactly as many globbing problems as, e.g., .cvsignore
>    con: would have to be some sort of filesystem-in-a-file,
>         not easily examined or modified by hand.

Also, this will suffer in large directories or when very many users doing
operations on the same dir since all operations will use (lock) the same
single file.

> I'd go for 5), if we could have a reasonable implementation for the
> metadata file, plus tools to view/modify the contents.

I'd vote for 1) any day.

my 2 cents

-- 
      Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Re: collected vs distributed working copy metadata

[Branko Čibej <br...@hermes.si>]

Here are some of the options as I see them:

1) Metadata in subdir of each directory

   pro: subdirs are easily detachable
   con: globbing problems, etc.

2) Metadata only in subdir of top directory

   pro: no globbing problems, except in top dir;
        export == checkout + remove metadata dir
   con: need special tool for detaching subdirs

3) Metadata in sibling dir of top directory:

   pro: no globbing problems at all;
        export == checkout
   con: no working copies for several projects off the same root;
        need special tool for detaching subdirs

4) Metadata in a completely separate tree

   con: Yuck (IMHO :-)

5) Metadata in _one file_ in each directory

   pro: subdirs are easily detachable;
        exactly as many globbing problems as, e.g., .cvsignore
   con: would have to be some sort of filesystem-in-a-file,
        not easily examined or modified by hand.


I'd go for 5), if we could have a reasonable implementation for
the metadata file, plus tools to view/modify the contents.
Otherwise I prefer 1), with possibly a safer name for the
metadata dir (oh, I can always "find . | fgrep -v /SVN").

    Brane

-- 
Branko Čibej                 <br...@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

Re: collected vs distributed working copy metadata

[Greg Stein <gs...@lyra.org>]

On Wed, Aug 09, 2000 at 09:17:31AM -0500, Karl Fogel wrote:
>...
>    2. It may be a bit harder to implement than just keeping all the
>       metadata in one place (presumably in the top of the tree, or in
>       a sibling of the top of the tree).  I'm not sure about this,
>       though, not having thought as much about implementing
>       metadata-in-one-place as I have about per-subdir metada.

Given an arbitrary subdirectory, how does SVN know where the metadata is
located? Does it just start walking up the directory tree looking for it?
How about third-party tools to work against an SVN working dir? Do they
repeat the scan?

I'm in favor of the per-dir metadata. None of this central stuff because you
don't have a way to point to the dumb thing. (and if anybody suggests and
environment variable, I will personally beat the crap out of you :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/