> > > But wait a second. Now my users are blissfully unaware that they are
> > > looking at versioned data, so they go moving things around willy nilly
> > > using the regular filesystem commands -- without using Subversion, and
> > > without "changing the paths in [the] config area". Now my working
> > > copy is completely out of whack! Where's the goodness in that?
> >
> > That's the same as now. Now they move directories around, and svn doesn't
> > automatically move the files in the repository.
> > But wait, there's a perl-script for doing imports, isn't it? :-)
>
> Erm... you've missed the point. Today, users move directories around,
> and those directories are still valid working copies that point to
> valid repository locations. Sure, they don't necessarily maintain the
> same heirarchy as what is in the repository, but they still work (sans
> implementation bugs), and since we're not hiding the fact that they
> are Subversion working copies, the users have a visual reminder that
> just using filesystem move operations might not be the best way to
> rearrange their data.
>
> You can't tout user ignorance as a feature when that ignorance is both
> unnecessary and burdensome.
Sorry, I don't seem to get my thoughts in a mail that can be understood (that
sentence proofs itself, doesn't it :-)
If I understand what you mean - you say that if directories are moved around,
you can still do a "svn up" or "svn ci" in this directories and everything
works. Is it that what you mean??
My point is - it doesn't matter whether the "dumb" user doesn't know better or
simply has no real chance to do better or anything like that. The user
currently has a fileserver which he uses, and I'd like to use svn as a backup
tool.
So the user may (rightfully) rename, delete or move, files and directories,
and (as long as there is no svn-aware filesystem - and I'm not sure that
WebDAV is the right answer, think file locking) there is no way that every
change will be tracked by svn-commands.
So all I can do at backup-time is to have a look at the filesystem. Which
files have just changed, which directories are missing, which are new?
Then it may be possible to make some claims - if a directory A is gone,
another B is here, but B has nearly identical files in it (see eg.
http://citeseer.nj.nec.com/manber94finding.html) (note: checking inode may
not work, as the user possibly creates a new directory and moves everything
over), then I MAY assume that the files have been moved.
I grant you - I don't know if such after-the-fact checking is in any way
"possible" (as dictated by practice, not theory) - it would have to be tried,
I believe :-)
Of course, the .svn-directories in the filesystem could be hidden by the
fileserver daemon, and this information could be used later to relink the
directory in the repository.
Hmmm, lots of things to think about, and not much time ... ;-)
Regards,
pm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 1 07:08:38 2003