Kristis Makris wrote:
Stefan, I'm sorry. TortoiseSVN is certainly not FUBARed. We wouldn't use
anything other than TortoiseSVN in Windows. And I know you clarified
with a lot of patience some things for us about the propset design.
Marek is trying to express his frustration with the current design. It
requires manual steps that we believe could be avoided.
Could have another look at my last email ?
Ok, let me have a look at your last mails:
Once you told that:
"We are trying to avoid any manual steps.".
Then, a few lines down you proposed:
No, but you could set "somewhere in the TortoiseSVN client":
- For repository http://some.rep/ apply these properties
- For repository http://some.other.rep/ apply these other properties
which is the exact opposite of "avoiding any manual steps". It seems to
me you're not trying to help, you're trying to prove my arguments wrong.
For every one of my arguments, you counter with another possible
"solution" just to show that I'm wrong, even you should know that your
suggestion doesn't work either, is even worse than what's implemented
right now, or what you told you yourself don't want it to behave like.
Then, you suggested having a config file on the server which clients
then would have to fetch in a separate thread from the repository when
showing the commit dialog (or whatever UI the client has for this).
If you *really* think about this, you would understand why I previously
mentioned that I don't want to contact the repository *at all* just to
show that dialog. No, please take a minute and think about it...
You thought about it? Still don't know why this is bad? Ok, here's why:
* the first thing the user does is write the log message, even if the
dialog is still checking for all modifications there are in the working
copy and need committing. And to write the log message, the bugtraq:
infos are required.
* imagine some flaky network connection (e.g. weak WLAN signal).
Fetching that file can take a few seconds, and sometimes even time out.
* fetching the file in a separate thread is bad. There are several
places in the 'fetch' function that can't be interrupted. If the network
is bad and the file can't be fetched, we have to wait a the timeout to
make that function return. And no, killing the thread isn't an option
because that leads to crashes.
You also might have noticed that the file describing the bugtraq:
properties couldn't have been written in one day. That's an indication
for you that we might have discussed all this way before you came here.
A quick search of the mailing list and you'll find all the discussions
about this, all the suggestions on how to implement this, all the
pro/con arguments, and why we finally decided to implement it the way it
is now.
Also, you say that "it doesn't need to be [implemented in Subversion ]".
Why not? I've given more than enough reasons why the current
implementation is the best we could do, and why better implementation
need to be done in Subversion itself. But still, you keep complaining
here. Why?
Go to the Subversion mailing list and complain there. Push *them* to
implement the feature, then *all* clients can profit from it, and much
better than with ugly hacks to work around missing features.
As long as I'm the only one asking for this feature on the Subversion
mailing list, the devs there won't think that it's important - after all
it's only one person asking for it.
So go ahead to the Subversion mailing list.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
