Julian Foad wrote on Fri, Sep 30, 2011 at 10:40:31 +0100:
> I think teaching "svn blame" to view the old repo would be harder:
> it would require more intrusive code changes in svn_client_blame().
> It's not theoretically difficult to do, of course, but perhaps the
> code-to-value ratio would not be worth having in libsvn_client ... hmm,
> unless we re-architect the blame code so that it's fed diffs from the
> client layer instead of fetching them itself, then it could be done
> really cleanly. The output format would just need a minor tweak to
> distinguish old from new revs.
>
How?
Perhaps some sort of N-ary identifier --- "%d.%d" % (repos_number,
revision-number) for the chain case, or "%s.%d" % (repos_path_from_root,
revision-number) for the tree case.
> I think teaching "svn diff" to do general cross-repo diffs would not
> be feasible with the current diff implementation. However, one of my
Why? If old-repos_at_rHEAD == new-repos_at_r0, then you could construct
a delta between old-repos_at_rM and new-repos_at_rN by combining the deltas
[rM, rHEAD] and [r0, rN], which then would allow the diff...?
> goals is to generalize the diff code further so it could support such
> things (cross-repo, unversioned local tree, etc.). That would be useful
> in theory, but in practice I can't see it really being used very often
> in this start-again scenario. But any single-rev diff is easily
> supported because the cut-over revision is present in both repos. (We
> can assume that the tree in old_at_OLD_HEAD is identical to new_at_1.) So
> maybe we'd want to make single-rev diffs and all same-repo diffs easier
> by tweaking "svn diff" to follow the specified path back into a revision
> in the old repo, a bit like what I said above for "svn log", if some
> special switch is specified.
>
> Any other commands or work flows that might be really useful? I
> wouldn't dream of trying to make "svn up" go back to the old repo, that
> would certainly be over the top. And I wouldn't expect "svn cat", "svn
Yeah, probably overkill, especially in the mixed-revisions case. (We
could somehow signal, via the UUIDs, that the two repositories are
related... but whatever; that's Future Work.)
You mention using 'svn up' for backdating. What about using it for
updating? i.e., in a working copy of the 'old' repository, to make 'svn
up' print an advisory message saying "Oops; the history has been
restarted; checkout a new working copy from %s" % URL?
> proplist" etc. to be worth bothering with, unless all such simple
> read-only commands get the same functionality "for free".
>
>
> Mad or genius? (And I know it wouldn't be worth bothering in a small
Yes :-)
> repository; let's assume it's a big and busy project with lots of
> interesting history.)
>
> - Julian
>
>
> [1] I'm just making up numbers here; I don't know what sort of numbers
> the customer that brought up this idea has.
>
>
Received on 2011-09-30 13:35:46 CEST