[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bundles Re: SVN, .SVN, and other meta-data directorys

From: Branko Čibej <branko.cibej_at_hermes.si>
Date: 2000-08-24 05:02:25 CEST

"Daniel L. Rall" wrote:
>
> Bill Tutt wrote:
> >
> > Greg Ward wrote a Python script to munge CVS's metadata to auto-repoint the
> > checked out tree to Python's new CVS tree at sourceforge after it moved away
> > from CNRI.
> >
> > So yes, people do manipulate the metadata files.
>
> I do this constantly, often on the command line. Here's an example of
> replacing the CVSROOT for a project:
>
> for d in `find . -type d -name CVS`; do echo
> ':pserver:foo@cvs.tigris.org:/cvs' > $d/Root; done; unset d

Such operations should be part of the working copy library API.
I know CVS doesn't provide a command to change the repository root,
but there's no reason why Subversion shouldn't do so.

In my (not so humble) opinion, metadata should _only_ be manipulated
via the Subversion client library. Tools that operate on the working
copy can issue SVN API calls to read the metadata instead of parsing
it themselves. This has several benefits:

    - We can change the format and contents of the metadata
      without breaking every tool. We only have to maintain
      API compatibility.

    - We can change the _location_ of the metadata. We can even
      allow different kinds of checkouts, e.g., one kind could
      store metadata locally in the working copy, another could
      leave it on the server.
      (Why? For instanc, someday we may want to implement something
      similar to ClearCase's dynamic views. Keeping metadata on the
      server would make that easier.)

    Brane

-- 
Branko Čibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70
Received on Sat Oct 21 14:36:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.