Kristis Makris wrote:
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 ?? **
Yes, it would work. But it has serious drawbacks. We've considered such
a solution before and have rejected it:
for every update/merge/commit/... we'd have to do a second
update/merge/commit/... either just before or after the original
operation (to sync that folder).
* this will slow down every operation
* since there are *two* operations instead of one, the user might have
to provide two times the authentication (if the auth data is not saved,
which a lot of people do for various reasons).
* those operations won't be atomic, which would bring us back to one
important reason why Subversion was even invented: CVS had this drawback
and had to be replaced because of this.
* how to name that folder? Just picking one is dangerous: some projects
might already use that foldername.
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 ?
If the repository browser is started from the working copy, TortoiseSVN
uses the properties read from that working copy, even if the operation
done in the repo browser is remote-only.
If it's not started from a working copy, we simply don't use the
properties. Reading them (or a config file) from the repository before
any operation would take too long.
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).
It has nothing to do with the size of the file or how many bytes are
transferred. The delay is 95% not data but
connect/authentication/request - once that's done, the data itself is
sent very fast.
(have you even used Subversion before? I think you would know that if
you have)
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.
* that file is not for users but developers who want to implement the
same features
* for users, the properties are described in our docs:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html
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.
But please, go now to the Subversion mailing list and ask them to
finally start working on those issues. As long as I'm the only one
asking for it, they won't think it's that important. Only if more people
ask for this, they will notice that it's an important feature.
http://subversion.tigris.org/issues/show_bug.cgi?id=1974
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
