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

Re: Review help: sparse-dirs deselection (issue #2843)

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 1 Aug 2008 00:19:33 +0200

On Thu, Jul 31, 2008 at 04:59:38PM -0400, Karl Fogel wrote:
> While I'm cataloguing my recent failures as a mentor, I should also
> mention the following posts from him:

I've taken a look at each of them. I have nothing much informative
to add but thought I'd post anyway.

> A trunk patch awaiting review (blocks some of his branch work):
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=141254
> From: "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn>
> To: dev_at_subversion.tigris.org
> Subject: Re: [PATCH] svn_wc_relocate3() on deleted target.
> Date: Tue, 22 Jul 2008 11:58:24 +0800
> Message-ID: <20080722035824.GC3941_at_Behemoth.ustc.edu.cn>

Reading the message, it looks like the patch is still incomplete.
You have discussed replaced and absent entries, but the patch as is
just handles deleted ones. Is there an updated patch somewhere?

Also, I cannot reproduce the problem by running the commands
given. For me, the switch command prints nothing and exists with
status 0, for both 1.5 and trunk. A "real" runnable shell script
that reproduces the problem would be nice.

> He asks an as-yet-unanswered question (related to r32264) here:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=141259
> From: "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn>
> To: subversion development <dev_at_subversion.tigris.org>
> Subject: Re: svn commit: r31987 - in branches/issue-2843-dev/subversion:
> libsvn_wc tests/cmdline
> Date: Tue, 22 Jul 2008 20:03:49 +0800
> Message-ID: <20080722120349.GE3941_at_Behemoth.ustc.edu.cn>

That is way over my head. No idea, sorry.

> And another unanswered question (about mergeinfo) here:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=141315
> From: "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn>
> To: dev_at_subversion.tigris.org
> Cc: Karl Fogel <kfogel_at_red-bean.com>
> Subject: Re: svn commit: r31986 - in branches/issue-2843-dev/subversion:
> libsvn_client libsvn_wc
> Date: Thu, 24 Jul 2008 22:44:02 +0800
> Message-ID: <20080724144402.GF3941_at_Behemoth.ustc.edu.cn>

This message reminds me that Julian said that we should check how
sparse checkouts interact with tree conflicts.

I agree that, for now, the merge can behave as if the missing item
was deleted, which is currently standard practice for such cases
(also known as "punting" ;)

But in the future, we might want to raise a tree conflict there.
Trying to merge something into an absent subtree is a tree conflict.
But you don't need to concern yourselves with that right now.
We'll take care of it later on the tree-conflicts branch, when we get
to the point of dealing with sparse checkouts.

As for the mergeinfo question:

I'm not entirely sure either how to handle mergeinfo for directories
that are missing because of sparse checkouts, but I guess as far as
the mergeinfo is concerned, it makes no difference whether the missing
path is a file or whether it is a directory -- a path is a path, right?
In other words, I guess that doing whatever is currently done for absent
files is fine for absent directories, too.

Then again, I'm not a mergeinfo expert, so please get advice from
someone more competent in that area as well.

> I'm going back to sleep now :-). I'll appreciate any help anyone can
> give Guo Rui, and I'll try to do as much of the above as I can too, of
> course. But I think I'm probably out of commission through the weekend,
> given the way I feel <blatant-appeal-for-sympathy shameless="true"/>.

Oh dear :(

Get well soon!
Stefan

---------------------------------------------------------------------
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-01 00:19:49 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.