SVN recursion on Windows cannot penetrate deep trees properly

[Oliver Dungey <ol...@gmail.com>]

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

Re: SVN recursion on Windows cannot penetrate deep trees properly

[Oliver Dungey <ol...@gmail.com>]

On 18/10/05, Oliver Dungey <ol...@gmail.com> wrote:
>
> On 17/10/05, Frank Gruman <fg...@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 :)
>


I have now got another very simlar scenario, steps:

1. created new branch
2. created new checkout
3. modified and moved around some files
4. performed a commit at the root of the view
5. lots of changes commited but not all!!!

So I tried systematically burrowing down the directories and performing a
commit and it kept saying nothing to commit until the very deepest directory
- and then the commit failed because not all the parent folders had been
commited i.e. major bustness.

Here is the transcript from my DOS prompt:

C:\svn\EJB>svn commit
C:\svn\EJB>cd Base
C:\svn\EJB\Base>cd 3rDeployment
C:\svn\EJB\Base\3rDeployment>svn commit
C:\svn\EJB\Base\3rDeployment>cd src\com\csc\rrr\deployment
C:\svn\EJB\Base\3rDeployment\src\com\csc\rrr\deployment>svn commit
C:\svn\EJB\Base\3rDeployment\src\com\csc\rrr\deployment>cd ant
C:\svn\EJB\Base\3rDeployment\src\com\csc\rrr\deployment\ant>svn commit
Adding .
Sending DeployTask.java
Sending ProfileTask.java
Transmitting file data ..svn: Commit failed (details follow):
svn: File not found: transaction '358-1', path
'/branches/EJB3-1/Release/JavaContactCentre/src/com/csc/evolution/deployment/ant'
svn: Your commit message was left in a temporary file:
svn: 'C:/svn/EJB/Base/3rDeployment/src/com/csc/rrr/deployment/ant/svn-
commit.tmp'

C:\svn\EJB\Base\3rDeployment\src\com\csc\rrr\deployment\ant>svn commit
DeployTask.java
svn: Commit failed (details follow):
svn: Entry for
'C:\svn\EJB\Base\3rDeployment\src\com\csc\rrr\deployment\ant\DeployTask.java'
is marked as 'copied' but is not itself scheduled
for addition. Perhaps you're committing a target that is
inside an unversioned (or not-yet-versioned) directory?

Re: SVN recursion on Windows cannot penetrate deep trees properly

[Oliver Dungey <ol...@gmail.com>]

On 17/10/05, Frank Gruman <fg...@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 :)

Re: SVN recursion on Windows cannot penetrate deep trees properly

[Frank Gruman <fg...@verizon.net>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: SVN recursion on Windows cannot penetrate deep trees properly

[Ryan Schmidt <su...@ryandesign.com>]

On Oct 17, 2005, at 12:43, 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.

Previous messages I read here blame this on Windows, that, when using  
relative paths, Windows has a limit of 255 chars for a path. And  
Subversion does use relative paths. Here's one message talking about  
this problem; there are probably many others:

http://svn.haxx.se/users/archive-2005-02/1050.shtml

I don't believe there is a solution at this time. I don't see a bug  
report about this situation either, but maybe I'm not searching right.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org