Stefan Sperling <stsp@elego.de> wrote on 11/27/2007 11:00:05 AM:
> On Tue, Nov 27, 2007 at 05:40:40PM +0100, Fabien Meghazi wrote:
> > > It is not possible to do this today. It would be a major rewrite of
> > > the client libraries to do this.
> >
> > I didn't realized it would required so much work. I was thinking about
> > a patch that would simply change behaviour of svn command like this :
> >
> > Pseudo Code
>
> > 6. if .svn folder is "marked" as "single .svn mode"
> > 7. # we are in the root of a "single .svn" repository
> > 8. set some variable state for further patching
> > 9. else
> > 10. # we are in a standard (not single .svn) repository
> > 11. set some variable state for further patching
> > 12. end if
>
> What are you trying to gain by creating two different ways of how
> the admin area is handled?
>
> In your proposal, the top-level .svn directory mirrors the working
> copy anyway, so your goal cannot be to improve performance.
Some users find all the "extra" .svn directories distracting. (Even
if they are hidden, etc.)
Some tools do not handle the "extra" .svn directories well. They
either are unable to correctly ignore the contents, or even worse,
tend to change/delete things in it when they shouldn't. (Think
Visual Studio and the .svn/_svn hack.)
Using the OS and copying a directory (and not ignoring) the .svn
directories can be dangerous if you copy from one working copy
directory to another. (Yes, you shouldn't do this, but users
do lots of things they shouldn't.)
If all the maintenance data was outside the normal tree, you just
wouldn't have to worry about any poorly designed tools.
I would hate to make the working copy code any more complex though...
You may want to take a look at SVK, which is built upon the svn libs, but
does not clutter the working copy with .svn directories, instead it
includes a whole copy of the repo in a separate area.
Kevin R.
Received on Tue Nov 27 18:18:35 2007