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
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.
- In other words, the current structure of
my_working_copy/
file
data-dir1/
file1
sub-dir1/
file11
.svn/
.svn/
data-dir2/
file2
.svn/
.svn/
with prop-base, props, text-base, tmp, wcprops and the
various files in every .svn-directory, would be changed into
my_working_copy/
file
data-dir1/
file1
sub-dir1/
file11
data-dir2/
file2
my_svn_area/
prop-base/
file.svn-base
data-dir1/
file1.svn-base
sub-dir1/
file11.svn-base
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
SVN_WC_BASES=/home/user/project1=/home/user/.wc/proj1:/home/user/project1/sub/sub/external=/home/user/.wc/proj2
- 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.
Summary:
We keep an identical tree as the working copy, just in another directory.
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)
+ 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
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.
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