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

[PATCH] Merging replacments of directories and Issue #2144

From: Ben Reser <ben_at_reser.org>
Date: 2004-11-30 23:34:55 CET

Philip or anyone else can you please take a look at the patch I attached
to Issue #2144?

The consequence of this patch is that we change some API promises on
svn_wc_ensure_adm(). Namely that you must pass the revnum set to 0 to
get svn_wc_ensure_adm() to ignore checking the revnum on a scheduled
deleted working copy.

I don't think this is a big deal. You can still pass zero. I'm just
allowing you to pass anything you want. I tend to think the requirement
of passing zero was a mistake since zero is indeed a valid revnum. If
we were going to have such a requirement we should have used
SVN_INVALID_REVNUM. But even then I can't really see a reason why you
would want to be calling svn_wc_ensure_adm() on a schedule deleted
directory when you wouldn't be intending to replace it and therefor
wouldn't care about what the URL or the rev of the existing dir was...

The test suite passes with this change and I can't see any implictations
of this patch...

Incidentally, the patch exposes a couple other bugs... Namely, reverting
a replacement of a copy doesn't remove the copy from url and rev from
the entries, that --dry-run doesn't work right with merges that replace
dirs, and that we're getting odd output showing that the directory is
deleted twice and that the indentation of the merge output is weird.

However, I consider these separate issues that I will go work on now.
But I wanted to get the review of this portion of the patch looked at

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 30 23:36:10 2004

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

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