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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Nov 23 18:54:57 2006