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

Re: svn commit: r32343 - trunk/subversion/libsvn_client

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 05 Aug 2008 13:16:09 -0400

Blair Zajac <blair_at_orcaware.com> writes:
> This commit and the previous r32342 fix this bug which you put a patch on:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3246

Yay, thank you!

> Do we want to use your patch?
> We could warn or fail if there is a duplicate external target. With
> the trunk code, we don't need to do either, but we could for a UI
> point of view.
> Even determining duplicate entries could be hard, as a user could use
> different types of relative URLs that still refer to the same absolute
> source URL. But then, depending upon the type of relative URL and the
> checkout URL, they could resolve to different absolute source URLs
> depending upon the checkout URL, so the comparison results would vary.
> So it's probably best just to check the external target and either
> warn or fail if a duplicate it found.
> Ahh, but then the user could have this
> dir1/ <- has external checking out at dir2/external-foo
> dir1/dir2 <- has external checking out at external-foo
> and our code wouldn't catch this case.

Well, I think the question of whether we want to apply my patch (or one
like it) depends on how the trunk code behaves right now.

If it will DTRT with duplicates, but just do it later (i.e., not catch
certain duplicates as early as my patch would catch them, but still
"catch" them, in the sense of either behaving reasonably with them or
erroring unambiguously), then I don't think we need my patch.

But if something could go silently wonky under the hood, and the user
might not find out till much later, then yes, we want some kind of patch
like mine. It sounds like there are a lot of different types of
"duplicate" scenarios here, and that the answer to the these questions
is not simple?

By the way, I don't like my patch as it currently stands, because it
errors out early and many perfectly fine externals could be left undone.
The reason I didn't commit my patch was that there was no way to
accumulate the errors and then display them as non-fatal warnings at the
end -- and I didn't have time to add the infrastructure to do that. If
we are going to alert the user, it should really be a warning, not an
error, IMHO.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-05 19:16:29 CEST

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.