Hello People,
I fiddled more with the problem below, and I think I found the problem. It
was a user error but it's very hard to spot, and probably easy to make even
after reading through all docs, so maybe it deserves a warning in the SVN
Handbook. (Which is, btw, a really nice think from the end-user's point.
Where to submit book patches? :))
I wanted to create a part of the repos which is pw protected, so I created
two <Location> in apache, one for /svn/ and other for /svn/private/, but
their SVNPath was the same (since I was thinking about permissions and not
separate repositories), while they were obvously overlapping.
This resulted chaos, as apache saw the same repository under /svn/private/,
while it did exist in /svn/ as well.
So this caused the actual problem.
(I go and check whether location without svnpath works or only hooks help
here.)
On Thu, Dec 05, 2002 at 02:31:20PM +0100, Rafael Garcia-Suarez wrote:
> Peter Gervai wrote:
> > After that I
> > svn cp http://host/svn/private/grin/something http://host/svn/public/
> > to publish it.
>
> What you probably wanted to do was :
> svn mkdir http://host/svn/public/grin (if it doesn't exist yet)
> svn cp http://host/svn/private/grin/something \
> http://host/svn/public/grin/something
>
> The command you tried apparently overwrites in some way the /public
> directory with the /private/grin/something directory.
Actually you're right, and I realised this several times (and forgot it
again). svn cp and mv works quite different from unix counterparts, which
moves under a directory if it does exist and not overwrite it. I checked the
svnbook but no big red flashy warning about this, so maybe it's just me
who got too used to unix syntax?
> Except that
> apparently it corrupts also the repository (if I understand correctly
> what you're saying below.) That's a bug IMO.
This probably was the result of the overlapping, but hard to tell WHY since
I'm a single person, so probably didn't make synchronous transactions (not
that it should matter due to db's locking and xactions). It could be some
kind of bug, but more subtle that I could even try to reproduce. Or simply
my kind of fool (setup) is smarter than the foolproofness of svn and db. :-)
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 5 16:19:18 2002