[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn working copy * not locked

From: Brian Fallik <fallik_at_assurtech.com>
Date: 2004-04-13 17:00:11 CEST

I will upgrade ASAP.

I had been using svn_load_dirs for these merges, so they originally came
from the same branch.

As for the 100% CPU utilization, it's hard to say. The size of the last
file svn completed processing was only 37k. The other files in that same
folder (whcih svn hadn't processed) are smallish (nothing over a meg).
Also, ctrl-C does not signal the svn client to terminate - I had to kill -9
the client in order to stop the process. Even if the client were waiting
for delivery of these files from the network, would that be a busy loop?
Svn should mostly wait on a select() in this situation, right?


-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, April 13, 2004 10:40 AM
To: fallik@assurtech.com
Cc: users@subversion.tigris.org
Subject: RE: svn working copy * not locked

On Tue, 2004-04-13 at 09:33, Brian Fallik wrote:
> Sorry for the missing version information! D'oh. Clients are svn 1.0.0
> ydl 2.3, server is svn 1.0.1 (r1) on redhat 9.

Definitely use svn 1.0.1 client; it fixed a couple of merge bugs.

> As to your last point, that's exactly it. I'm trying to merge the changes
> from two versions of source code (think of them as vendor branches) into a
> third branch. It appears like this is going to require more effort than a
> simple merge. I'm now realising the usefulness of the --dry-run option.

Yah, this is why there's a whole section on vendor branches in chapter
7. If you simply imported two vendor releases into the repository (i.e.
the repository has no idea that the trees are supposed to be related)
then you might want to use the svn_load_dirs.pl script to help you
deduce changes.

As an alternative, you can also try running 'svn merge
--ignore-ancestry'. This will make the merge operation "more dumb" and
just do path-based comparisons, rather than comparisons based on
node-relatedness. It *might* help you out here.

> Another characteristic I'm noticing now is that during my dry-run merge,
> svn client uses 98% and about 10 mins of CPU time (from top) processing a
> single file.

Is it a huge file? 'svn diff' and 'svn merge' download fulltexts from
both trees that you're comparing. Perhaps you were just waiting for the
CPU to download the file from each tree.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 13 17:00:48 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.