Ruediger.Dohna@oxaion.de wrote:
[...]
> it lends itself as a natural place to store Subversion metadata as well,
> rendering the .svn directory altogether dispensable, [...]
This is an interesting idea. There are two levels at which we could use
filesystem metadata storage:
* just for storing the Subversion "properties" on an item;
* for storing all Subversion meta-data that is currently in the ".svn"
directory - pristine (base) copies, information about which
repository/path/revision the local files are connected to, etc.
You seem to be talking about the latter.
Of course a fair bit of work would be required to do this, so it would need to
have some distinct advantages.
> Even better: Moving, duplicating or renaming such
> a file or directory would keep the metadata intact and attatched to the
> file [...]
That is currently true for a directory but not for a file. Below, you suggest
that Subversion might automatically find the new item and save you from having
to tell it that you moved it, but I don't think that's practical. Can you give
any other example of a situation in which it would be useful for a file to keep
its metadata with it?
> A whole bunch of problems working with versioned files without
> subversion tools would simply disappear, including double matches in find
> tools, etc.
Avoiding double matches in find tools is one advantage; that problem still
annoys me fairly frequently. Can you list some other advantages?
[Disadvantages]
> 1. Removing a file or directory would remove its meta data as well. In
> order to know that something is missing, the directory would need to have a
> list of known objects,
Yes. Also, if we still wanted to allow a deleted file to be reverted
(restored) without network access, we would need to keep the file's pristine
(base) text in the directory's metadata.
> so it can look for the same object with a different
> name or at a different location (which still would have the old metadata)
> in order to tell the repository to rename, move or even remove that object
> (I do not think that we should have the user explicitly mark it as deleted
> any more).
Here you are talking about a different mode of operation, a mode in which
Subversion acts as if an "svn delete" command has been issued if the local file
is gone, or "svn move" if the file has been moved, and so on. (In order to do
things like make a local back-up of the file, and avoid Subversion adding it to
the repository, we would also need a command to tell Subversion to forget about
a particular file while leaving it on disk.)
a) Could Subversion really, practically, look for an object that has
disappeared (been moved/renamed/deleted)? Assuming it could identify the
object (with a unique ID, say) if it found it, where would it look? I think it
would have to look "everywhere", which is not practical. Sometimes it might
find it quickly, nearby, but if deleted it would have to search the whole file
system. The only practical way I can see is for Subversion to hook into the
file system and be notified of move/rename/delete operations. A program
operating in that way would be a completely different sort of Subversion client
from what we have now.
b) How would the use of filesystem meta-data storage facilitate this mode of
operation? OK, it would make it easier to identify whether and how a
particular file is connected to Subversion, but it doesn't fundamentally make
it possible. It seems to be a completely separate issue.
I can't yet see a compelling reason to use filesystem metadata storage.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 6 15:34:44 2006