On Thu, Feb 7, 2013 at 12:47 PM, Dale McCoy <dalestan_at_gmail.com> wrote:
> On Tue, Feb 5, 2013 at 6:51 AM, Ben Fritz <fritzophrenic_at_gmail.com> wrote:
>> Why couldn't TortoiseSVN have a tool to find a revision to update to,
>> based on date?
>>
>> TortoiseSVN could query the log (using the svn library) to find the
>> commit date of each revision, compare the commit date to the date
>> specified by the user (internally, NOT using the svn library), and
>> update (using the svn library)
>
> Should TortoiseSVN request the whole log (Consider that the subversion
> library is around revision 1,500,000. And yes, there are seven digits
> in that number.) every time someone tries to update-to-date?
> Or should it only request some subset of the log? What subset? What is
> the average-case and worst-case number of requests required to find
> the correct revision?
>
> And then TortoiseSVN should grace every server blessed to be mentioned
> in an svn:external with the same request or set of requests?
>
> Somehow I'm thinking you're going to have a hard time selling the
> server admins on this idea, even if you convince everyone else.
>
"Update to date" is going to be a rare operation. Normally a simple
"update to head" is all that is needed. Rolling back to an older
version isn't all that frequent compared to getting the latest
changes.
Secondly, the sort of server load you fear already happens when
someone wants to do this "update to date" manually.
What would a user do right now if they wanted to see what the
subversion library looked like back on February 29, 2012? They would
probably look at the svn log and scroll until they see a commits prior
to that date, then scroll back slowly until they found the exact date.
This fetches a large number of log entries as well, it is just a
manual process instead of automated. An automated method could
probably use a binary search (as mentioned by Dale) to reduce the
number of entries actually requested. This would be much harder to do
manually, so you'd actually be saving bandwidth.
If you put externals into the picture, after the user found the right
revision of the working copy, they would then need to find each
svn:external directory and do the same thing. Probably they already
updated the externals to whatever revision was specified in the
update, which was wasted server bandwidth in the first place, since
they don't want that revision. If TortoiseSVN can be smart and only
download the externals once (after determining the correct revision),
you actually use far less bandwidth for this operation.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3048044
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-08 00:51:39 CET