On 18/10/05, Oliver Dungey <email@example.com> wrote:
> On 17/10/05, Frank Gruman <firstname.lastname@example.org> 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:
> 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:
Transmitting file data ..svn: Commit failed (details follow):
svn: File not found: transaction '358-1', path
svn: Your commit message was left in a temporary file:
svn: Commit failed (details follow):
svn: Entry for
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?
Received on Wed Oct 19 13:36:45 2005