On 7 February 2013 23:51, Ben Fritz <fritzophrenic_at_gmail.com> wrote:
> 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.
Typically we (i.e. Stefan) might add such a feature either if it is
likely to be used a lot, or if it automates a manual process which is
tricky, has many stages or is error-prone. This one by your own
estimation falls into neither of those categories. Given the limited
development resource that TSVN has I would say this not going to be a
priority.
> 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.
As Oto says, the dates are not necessarily ordered (e.g. when
combining two repositories using dump/load cycles) and they are
mutable, so the search is not trivial. And in the manual search the
log cache will help after the first time anyway.
> 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.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3048101
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-08 10:59:28 CET