On Tue, Jun 3, 2008 at 10:25 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
>> This is fixed on trunk and nominated for backport to 1.5.x. We're
>> currently debating whether it really needs to make it into 1.5.0.
>> Given that this is the second or third independent report of this bug,
>> I'm starting to lean a whole lot towards putting it in 1.5.0. What is
>> the point of having release candidates if we don't fix the most
>> reported bug?
> Well, the point is also to know what we're sending out there, so we can
> document known problems, be prepared for certain feedback, etc. Of
> course, getting the fix in is the ultimate goal. But is it worth
> extending the soak? I'm not so sure.
> I'd also like to know whether Bert's recipe was derived from something a
> client (like Ankh or TSVN) did. If so, the workaround is for the client
> to protect against using --depth=empty on a file, which is what TSVN has
> done now IIRC. If the common clients do that, the bug is likely to hit
> a lot fewer users for the short time that it's out there.
> Bert, did this really come from command-line usage?
In Subclipse we have a couple different ways to do Update.
One of them brings up a dialog where you can specify the revision and
the depth. In this, someone could conceivably specify Empty. Like
TortoiseSVN, the dialog always defaults the depth value to "Working
Copy" which is the depth=unknown (-2) value. I do not think it is
real likely that someone would do this. About as likely as someone
typing it in on the command line. Meaning it will undoubtedly happen
to someone, but should not be an epidemic.
The other UI is driven off svn status -u and it shows you available
changes from the repository. When you update from this UI there is no
dialog. When we call the API we explicitly pass the value for
depth=unknown (-2). We also are explicitly naming all the targets to
update. I suspect this is the place where TortoiseSVN and AnkhSVN
were passing empty. I can see why they would have done it. They
probably called the old API with the recursive boolean set to false,
and this seemed the natural equivalent.
I suppose if they had a GUI that showed incoming changes and that
included a folder and some files beneath it, and the UI allowed the
user to select the folder, and some, but not all of the files, then
they might want to be able to pass depth=empty so that only the
specific selections were updated.
I could still go either way on this one and certainly do not object if
we want to do an RC9. I'd like to see us reach a decision though as
we could have done it last week.
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-03 16:36:17 CEST