Julian Foad wrote on Fri, Sep 30, 2011 at 12:17:09 +0100:
> To record my own opinion: I think it's a fine idea that users in that
> situation should be able to do that sort of thing but I don't think that
> functionality belongs in "svn" as I think it's an uncommon use case and
> can't be cleanly and generally supported -- it's rather a hack. If we
> supported third-party client-side plug-ins that's where it would
> belong ... but we don't have any plans to do so.
>
Could this be implemented via a wrapper libsvn_fs_* or libsvn_ra_*
module?
libsvn_fs_raid0 or libsvn_ra_raid0.
> - Julian
>
>
> I (Julian Foad) wrote:
> > 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:41:39 CEST