Hello,
First sorry to reply that way, I did post something on that list before I figured out I did not subscribed to it ...
Second, I must say how much I appreciate turtoise and svn and despite the few remarks I place here, there is
no doubt in my mind about the fact it is a superb realisation. Now, superb does not means it may not be perfected,
therefore here a 3 propositions (I replied Stefan), which have (at least for me) some sense.
Best Regards,
Vincent.
Valérie et Vincent wrote:
> We are using turtoise at work since a few months, and we think we
> know it enough to be able to ask for some improvements.
>
> 1 - Have externals being visible in repo browser.
> We use them a lot (it was the reason for us to switch to
> subversion), we think it could be a very efficient feature. More, no
> other repo browser (instead a "crapily" modified websvn we hacked)
> offers that !
There's a reason why no other repo browser has this feature.
To find out if there are any svn:externals present, we'd have to read
the properties of every folder in the repository. That's slow, very
slow. Because it requires a server request for every folder.
<Vincent> I understand that point, but for me :
- It makes externals more difficult to use, where I think that is one of the major
features which makes svn & turtoise certainly one of the best configuration management solutions,
even comparing to most of the commercial solutions.
- It could be an option, at the end of the day, users would see if this performance issue is a real problem for them,
depending on the network architectures, activating such an options may be something affordable depending on your
repository size and the network bandwidth that's available. On our site, we someone hacked websvn in a way we see
the external links, and our repo size makes that feature being extremelly appreciated (even though is it a "not-so-pretty" hack).
</Vincent>
> 2 - Warn when merge happens !!
> It brought with some surprise !!
> SVN does it, but does not warns (except it sends a message
> telling so), would it be possible to have a warning when this happens ?
If you don't want automatic merging, set the svn:mime-type property to
something other than text (e.g. application/octet-stream).
Imagine for a moment what you're asking here:
* user starts updating a big working copy
* about 50 files got modified, 10 of those are modified by the user
himself too
* during the update, a dialog pops up 10 times warning about a merge
The only thing you would get with that: users complaining. And after the
third dialog, users won't even read the dialog box anymore but simply
click ok to get rid of it.
It wouldn't help at all - it would only hurt.
<Vincent>
I disagree with your last point, people, and developpers especially don't like the
idear of having someone modifying their code without telling. Merge without at least telling
is something people dislike.
Therefore it would not hurt, simply because merging should be something quite unusual, which
happens not so often. But as it is one of the basic principles of svn (opposingly to locking), I
would have imagined something telling about it.
</Vincent>
> 3 - Make the browser memorise the destination directory
> This is a very interresting feature, especially with huge
> repositories.
> When you check out, you set the destination directory of a given
> place of the repository and, when requested to check out, the included
> directory are proposed to be stored at their parent's directory,
> concatenated with the current one name.
> This feature is certainly the only one I would take from Visual
> Source Safe and which is currently missing.
Use a nightly build from trunk.
<Vincent>
Sorry, does it means the feature exists ?
</Vincent>
Stefan
Received on Wed Feb 7 23:00:07 2007