Re: Feature Request: svn:externals dialog update...

>>>> If you really want to keep 100% consistency between the server
>>>> capabilities and the client user interface, the simplest solution is
>>>> to use clients and servers from the same generation...
>>> SVN itself supports interactions with multiple combinations of
>>> clients and servers. TSVN should not break that capability.
...
>> I think you may have misread what I wrote. I'm not talking about
>> compatibility, I'm talking about user interface consistency.
>> IMHO TSVN keeps compatibility; by offering the "Advanced" edit field.
> You still seem to miss the point that it is a forced conversion and
> TSVN is the only tool doing such a forced conversion.

I don't agree that it is forced if you have an option (by using the Advanced dialog) to avoid the conversion. It is a conversion by default, by hardly a forced one.

> Forcing people to have to use an Advanced dialog to maintain
> compatibility is not maintaining consistency when that use to be the
> only dialog for editing the svn:externals property, and the new
> dialog offers no method of maintaining compatibility.

My point exactly. TSVN does not maintain 100% GUI consistency towards all older server versions. Except for the extra work this would induce it would also make it more difficult improve the average user experience by introducing new and improved dialogs.

> Perhaps the better solution may be to simply have the new dialog
> detect the format on edit, if it's the old format ask whether or
> not they want to switch the formats, and if not switch to the
> Advanced dialog and notify the user that they need to use that
> dialog instead.

Hey! This is an excellent idea. If there is a simple way to detect the old format it would probably be a very good feature!

> The point is, the user should have to make the choice to upgrade
> the format, not the software without even telling the user it is
> doing so as is presently the case with TSVN.

You have a valid point here too.

>>> TSVN should do the same without forcing people to have to remember
>>> how to do it all the time as it only takes one slip-up to break the
>>> system in that case.
>> If it is that easy to break your system, I would strongly suggest
>> that you implement a server side hook that prevents those kinds of
>> commits.
...
> I doubt a SVN hook would be sufficient and only cause confusion as
> both formats are 100% valid.
> Furthermore, hooks tend to be repository wide, and not all projects
> have to follow the same rules - that is, some projects may only have
> developers on TSVN while other projects have code go through TSVN
> and other SVN clients.
> Why force all projects to do exactly the same thing?

Uhm. If you need to _enforce_ the use of the old externals format, a server side hook is the way to do it. There's no way around it.

And no. Although most hooks are enforced repository wide, there is nothing that prevents you from writing a hook that is only in effect on a certain sub-tree in your repository, or most any other constraint you would like to use. It's only a hook script. It can do anything you like.

>>> Well, from what I understand TSVN has a specialized environment which
>>> I don't have the capabilities to build on Windows; nor do I have the
>>> time to setup at the moment. I have considered it.
>> It's not very specialized. It does requires a very recent version of
>> Visual Studio though... :-/
> And dependency libraries (libsvn, libneon, openssl, etc.)?
> That's where the PITA comes in, no?

Yes, there are a number of dependencies that needs to be manually installed. I would love to see this being automated, but it's not really that huge of a PITA. But I guess that really depends on your pain threshold. ;-)

Hans-Emil

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2876830

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-10 09:47:53 CET