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. _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
