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

Re: Idea regarding working copy, .svn location, and some more

From: <cmpilato_at_collab.net>
Date: 2003-07-30 17:13:24 CEST

pmarek@users.sourceforge.net writes:

> - We define an environment variable (and/or a file/an
> entry in ~/.subversion/) with a list of working copies,
> mapped to other directories. eg
> SVN_WC_BASES=/home/user/project1=/home/user/.wc/proj1:/home/user/project2=/home/user/.wc/proj2
> so the working copy which has it's text files in
> /home/user/project1 would use a tree in /home/user/.wc/proj1
> for storage of .svn-data.

No. No no no. Why an environment variable? Isn't that what we have
a config area for?

> - svn:externals could be done this way too, if the definition would
> be like SVN_WC_BASES=/home/user/project1=/home/user/.wc/proj1:/home/user/project1/sub/sub/external=/home/user/.wc/proj2

The point of svn:externals is that not every user has to set them up
for themselves. One person figures out the right layout, sets a
property, commits, and now everyone else on the team shares the bounty
of his effort.

> Pro:
> + eg a fileserver can easily be versioned, without user irritation because
> of the .svn-directories (samba may hide them; but if a user deletes a
> directory, the .svn therein gets deleted too, and that confuses svn)

Deleting a Subversion directory does not confuse Subversion. That
directory is noted as missing, and can be retrieved again using 'svn

> + saving of a few inodes (the repeated .svn-direcories vanish as the tree
> is summed in one location)

Really stretching for "pros" here, aren't you? Let me help:

  + get to name your administrative directory anything you want to,
    including (but not limited to) .pmarek-is-my-hero

> + maybe a consolidation between export and checkout/update

That's sufficiently vague. What about our current .svn layout hinders
such a consolidation today?

> Con:
> - Work has to be done
> but that should be limited to subversion/libsvn_wc/adm_files.c
> open_adm_file() (*)
> - complexity
> - possibilities of error
> - environment may change from one user to another, and the
> ~/.subversion does too. So maybe we should record the root in the
> .svn/entries-file like the repository-uuid.
  - working copies are no longer relocatable unless we implement yet
    more subcommands like 'svn pack' and 'svn unpack'.
  - can't even tell that a given directory is a versioned one without
    attempting an operation like 'svn st' on it.

> And to be honest, I see a lot of advantages. and if all that is needed for
> step 1 is to change open_adm_file() - why not ??? (yes, yes ...
> feeping creaturism and so on)

Really? Your "pros" list was a little lean, IMO.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 30 17:14:41 2003

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.