[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-13 16:39:34 CEST

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 on
> 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, the
> 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 16:41:45 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.