I want to share with you an idea that came to me from a customer. I'm
not at all proposing that anybody should do this, I'm just curious what
you think.
Imagine, if you will, that we are coders working in a Subversion
repository that has grown very large and that for IT reasons a decision
has been made to freeze the repository -- make it read-only -- and a new
repository has been created, taking a snapshot of the old HEAD and
importing that as the new r1. We are to continue our development work
in the new repository.
Those of you who are "old" enough svn devs, think back to when
Subversion became self-hosting, starting with a snapshow of the head of
the CVS repository. All the prior history was back before r1,
inaccessible via Subversion. Was that a big problem? No, it wasn't,
and I know that the snapshot approach is often recommended as a
pragmatic and perfectly reasonable way to migrate from one VCS to
another. But maybe this time there will be hundreds of developers
working in dozens of projects[1].
As Subversion devs today we might like to say "no, don't do that, let's
find a better solution to whatever problem was forcing us to re-start
with an imported snapshot". But imagine that's already been discussed
and this is the best way forward and now we simply have to get on with
using the new repository.
Q: What simple modifications could "we" (anybody) make to our
Subversion clients that would help us to work more effectively in this
scenario? The customer I got this idea from is more interested in
TortoiseSVN than in "svn" and asked me a somewhat different question,
but I think this is the general idea that's of wider interest.
A: What do you think?
Maybe one of the most useful things we could do is teach "svn
log" (when running in the usual 'backwards' direction) to run a
follow-on log in the old repo if and when reaching r1. Perhaps we'd set
a revprop on (new) r0 or r1 pointing to the old repo URL so that this
info is configured in a single place. The two sets of revision numbers
in the output would be confusing so we may want to consider tagging the
old and/or the new revnums with some marker as well as inserting an "And
now from the old repository:" message.
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.
I think teaching "svn diff" to do general cross-repo diffs would not
be feasible with the current diff implementation. However, one of my
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
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
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:15:19 CEST