On Mon, Feb 4, 2013 at 1:48 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> As I said before in this very thread you're replying to:
> * first of all, updating is done in the svn library. Which means this
> must be done in the svn library and can not be done in TSVN.
> I don't think that what I wrote could be confusing.
It's not confusing, but it doesn't mean TortoiseSVN couldn't implement this.
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) to the last revision prior to the date
specified by the user. This is easy for most updates. The user doesn't
care HOW TortoiseSVN implements "update to date", whether it be done
directly with the underlying svn library, or with some quick
preprocessing and/or post-processing; they just care that it's
svn:externals makes this a little harder, but after the svn update
each external pulled in could be individually updated as well. This
would probably be the tricky part; but if I understand correctly each
external can accept operations like switch and update as well even if
this is a little weird.
Maybe svn:externals can be ignored by an update-to-date feature,
especially if some automated method could be designed to allow pulling
the HEAD of svn:externals normally but still updating to the historic
revision. Obviously the svn library doesn't currently support this,
and it could be trickier (but more valuable) to create an automated
wrapper around it.
recommends that users always specify a specific revision for
svn:externals items. The problem is that developers are lazy and doing
this takes extra overhead to maintain. I think a separate command, or
an option in the update-to-revision dialog, would help here. The
dialog would allow the user to select which externals definitions
would be affected. Then the svn:externals property of those versions
would be changed from the current specification to the latest revision
on the same path. I.e., only the revision number would be changed for
specific revisions. Then an svn update would be performed. The user
would need to commit these working-copy changes to svn:externals. If
this were incorporated into svn update somehow, then users could
continue working with the latest version of libraries, etc. most of
the time, but still go to specific versions using "update to revision"
as allowed by specific svn:externals revision numbers.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-05 12:52:23 CET