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

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

From: <pmarek_at_users.sourceforge.net>
Date: 2003-07-30 07:36:22 CEST

Hello everybody,

browsing through the issues I found some wishes
regarding the .svn-directories; namely the issue
regarding a compressed text-base, a non-existant
text-base, and opaque collections (issue 707)

Now I had the following idea.

- We define an environment variable (and/or a file/an
entry in ~/.subversion/) with a list of working copies,
mapped to other directories. eg
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.

- In other words, the current structure of
with prop-base, props, text-base, tmp, wcprops and the
various files in every .svn-directory, would be changed into
with similar trees underneath props, text-base, wcprops, and (if needed) tmp.

- If svn should operate in a directory, which is a subdirectory of one of the
given directories (via environment or config-file), it knows where to keep
it's data.

- There would be a new parameter to checkout (--with-svn-data DIRECTORY).
It would set the value in ~/.subversion/, if the environment was not
already set.

- svn:externals could be done this way too, if the definition would be like

- In effect we could define a root-directory for the working copy.

- This would allow us to store per-working-copy-attributes; like my most-wanted
"save-timestamps"-property :-) or the famous "opaque collection".
ie on checkout or at a later date you can set properties on the root-directory
which will be known in every subdirectory, as the root can efficiently be found.

We keep an identical tree as the working copy, just in another directory.

+ 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)
+ saving of a few inodes (the repeated .svn-direcories vanish as the tree
  is summed in one location)
+ a working copy has a defined root, which allows us to store per-working-copy
  attributes. This gets us settings like "use saved timestamps on checkout
  and update"
+ maybe a consolidation between export and checkout/update
- 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.

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)

Opinions, please??

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 30 08:15:54 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.