Again, I'm sorry. We could have communicated our ideas in a more
positive way. There's no doubt that you have the most knowledge and
experience with the problems implementing this in TortoiseSVN. And I
know, too, that building open source software is a laborious process.
I know I've had to think in different ways after reading your answers,
and seeing the underlying issues.
> 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...
>
> * 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.
There are two ways for a user to commit in a Subversion repository:
1) He checks out a directory. Makes local modification and then commits.
Would it be possible to have TortoiseSVN also checkout
3rd_party_config/tortoisesvn.config when the directory was originally
checked out, in a single trip to the server ? When the user wants to
write the log message, the bugtraq information would already be
available. The repository would not have to be contacted at all, and the
user would not have to wait to bring up the commit dialog.
*** Do you think the above could work ?? **
2) The user applies an svn copy directly on the repository (remotely). I
don't know how the bugtraq properties are received for that. Can you
help ? Would this be a problem ?
My first guess is that you would have to contact the remote repository
to get the properties. Either propset properties, or config file
properties. I would imagine that retrieving tortoisesvn.config and
retrieving the propset properties from the root directory would take
about the same time. We don't expect the properties file to be that big
(again, just a guess).
> * imagine some flaky network connection (e.g. weak WLAN signal).
> Fetching that file can take a few seconds, and sometimes even time out.
Certainly, waiting to read the properties to bring up the commit dialog
would be bad. You made it clear that waiting there would be
unacceptable. If we avoid this altogether (as proposed above), network
connectivity wouldn't be the problem.
> * 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
That's true. We shouldn't get into that.
> You also might have noticed that the file describing the bugtraq:
> properties couldn't have been written in one day. That's an indication
I don't understand what you mean. Could you clarify please ? Are you
saying that the file would be complicated for a user to write manually ?
If so, perhaps a window from the TortoiseSVN client could make this
easier for the user.
> 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.
I'm sorry. We were looking for quick answers from someone who might
know. We didn't search the mailing list or the bugtracker. We only read
the FAQ.
> need to be done in Subversion itself. But still, you keep complaining
> here. Why?
It seems that, in summary, we are proposing a way that feels more
suitable for our needs. It doesn't have to be mutually exclusive with
the existing implementation of properties. Perhaps the user could select
a checkbox selecting between propset properties and config file
properties. It seems that for Marek's development environment the
expectation that properties have to be set manually on every folder is
overly taxing for him, and he might be willing to live with the
expectation that a config file has to be checked out once during the
original directory checkout.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Nov 22 23:04:49 2006