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

Re: Renaming folders locally - Feature request/Bug report

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 05 Feb 2009 19:33:17 +0100

jwezel wrote:
> Hi Stefan,
>
>> In that case, the folder would appear as unversioned in the commit
>> dialog. It's up to the user to decide whether that folder should be
>> added and committed.
> Sure - exactly this shall happen! The user sees the folder as usual to
> be a candidate for adding/commiting - it is the existing logic!
>
>
>> And: if you have something as "do that OR do that" in your code, that's
>> a very clear sign that something is wrong.
> I assume your referencing to this sentence below:
>
>>> // 2. either drop the folder and download it again from the svn
>>> server OR just change the references inside of the subfolder structure
>>> to the new path of the directory in the SVN server repository
>
> Well, this is not a decision of runtime/code, this is the decision of
> the programmer how he implements it. These are 2 possible ideas; one
> is faster to implement than the other one, but the other one is the
> more nice solution. So it's just the decision of how much time you are
> able to invest into it ;-)

Ok.

>> No, definitely not.
>> You're forgetting about the concept of "nested layouts" (read about that
>> in the svn book please).
> Nested layouts are still fully supported; I don't see a problem here.
> Where do you see it?

No, because you want TSVN to automatically correct such situations. But
some users might not want that and actually knew why they renamed a
folder - to create a nested layout.

There are several problems with your approach:
* users might rename stuff deliberatly (I do that often)
* doing stuff automatically is dangerous
* it won't work reliably anymore as soon as more than one folder is
renamed (which one was which one before?) - comparing the urls won't
work either, because it could be an (existing) nested layout or an external
* it takes a *lot* of disk access and time to scan the working copy for
such situations - a lot of users have working copies several gigs big

And as I mentioned: it's simply not possible to detect such renames
reliably. There's always a situation where the detection would fail.

But: the commit dialog already shows the renamed folders as 'nested'
(the status column shows it) so users know that something is maybe(!)
wrong and then they can check what it is and fix it themeselves.

If users don't see that, they also wouldn't see whether an automatic
'fix' really worked or they wouldn't understand the dialog shown if TSVN
would ask them whether to fix the issue. So they would be screwed anyway.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1108648
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-02-05 19:46:07 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

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