> > My argument for a default separated meta-data approach for
> > non-power users is that it reduces the chance for user error with
> > respect to the .svn/ directories. In other words, these average
> > users are not going to be doing the complex things described
> > previously in this thread. They will often have one single
> > working copy for each project, and very likely will be only
> > working on one project on one machine at a time.
>
> Are you sure ? I bet you'd be seeing a lot of "I moved my
> working copy and now
> I can't do commits and updates" mails when the separated
> meta-data approach
> is taken...
This could be anticipated, and resolved by an intelligent error message when
the user runs an svn command which can't find the repository. Something
like, "subversion attempted to access a working copy that is not in the
expected location. Please tell subversion where to find it with the command
'svn wc relocate <path/to/old/wc><path/to/new/wc>' or 'svn wc remove
<path/to/old/wc>'". Note that these commands work in two cases: 1) the user
already moved the wc with mv, in which case the command would merely update
the metadata, 2) the user wants to move or remove the wc, in which case the
files will be moved or removed as specified.
> the .svn directories avoids this problem and make
> it more obvious
> for people that there _is_ meta-data (at least when they're
> not hiding dot-files).
Um... files and directories preceeded by a . are by default hidden on *NIX
boxen. If the non-power-user is supposed to see it, then why name it such
that it will be hidden by default? The more basic question seems to be, "how
aware does the user need to be of the metadata?"
As an aside, I've noticed that I often need to check to see whether a
directory is a wc or not. The simplest way is to "ls -la | grep svn". If the
metadata is relocated, perhaps the command "svn wc" with no additional
parameters, could return something like "your/local/path is [not] a working
copy."
--- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 28 08:38:07 2003