On 17/10/05, Frank Gruman <fgatwork@verizon.net> wrote:
>
> Oliver Dungey wrote:
> > Subversion version: 1.2.3
> > Platform: Windows XP service pack 2
> >
> > We have been using Subversion for 3 months now and have been
> > experiencing strange problems when performing commits and cleanups. I
> > have been tracking the problem in our team and it appears that when
> > doing an commit/cleanup on the root of our repository it doesn't reach
> > the bottom of the tree. We have used the svn command line, tortoise
> > and the eclipse plugins but always get the same results. In the last
> > week we have been trying the pure java implementation via the eclipse
> > svn plugin and this does not appear to have the same problems.
> >
> > I don't know anything about the API calls into the Windows platform
> > that subversion uses but I do remember from years ago that some of the
> > C++ recursion functions can fail with deep trees due to hard coded
> > path depths of 256-1024 bytes.
> >
> > I have waited a month or so to report this issue hoping that we could
> > get firmer information but haven't managed to achieve any more than
> > I've got above.
> >
> > Oly
> Although I probably can't solve the problem, I recall a posting similar
> to this a couple months back. Have you tried to search the mailing list
> for this issue?
>
> Also - to help clarify the problem, can you give specific details (steps
> to recreate the problem) so that we have a visual of what your system
> looks like / is doing when this occurs?
>
> Regards,
> Frank
>
Some more detailed info ....
Path in question:
C:\svn\3rTrunk\Release\3rClient\src\com\csc\rrr\client\implementation
What happens?
1) I change more than one code file in this directory.
2) one of my co-workers updates their svn checkout having modified the same
files.
3) merge/conflict proceedings should commence for all the files in conflict
but this is where things appear to go wrong ....
a) if they try to do an update from the root of the checkout svn says
nothing has changed (via svn command line, tortoise or eclipse plugins
(except for pure java version in the eclipse plugin)).
b) they try to do a commit and get locked messages.
c) they do a clean and it doesn't do much to help them
d) they go to a lower folder in the tree and do update and if they are lucky
and have stumbled on the correct directory an update appears and goes into
conflict.
e) they fix the conflict
f) they try and checkin from the folder again
g) lock messages again .... goto d) and repeat until all conflicts are
flushed out of the system.
I am not convinced I properly understand the pattern but at this point that
is as accurate as I can be. The main thing is that you get stuck not being
able to update/commit or clean your whole checkout and have to 'persuade'
svn to tell you about conflicts until you flush them all out ..... and this
takes a very long time :)
Received on Tue Oct 18 14:21:28 2005