Ramkumar Ramachandra wrote on Sat, Sep 25, 2010 at 11:59:49 +0530:
> Daniel Shahaf writes:
> > Would svnrdump benefit if, once 1.7.x branched and RC's start being
> > rolled, it were subjected to a more relaxed backporting policy?
> > If so, we might consider moving it to tools/ for 1.7.x, with intent to
> > move it back to subversion/svnrdump/ for 1.8.x (as soon as 1.7.x is
> > branched from trunk).
> Hm? I don't understand how it'll help backporting. I already maintain
> an out-of-tree build that successfully compiles against 1.6 . It'll
> be fairly trivial to write an svn18_compat module.
We'll be able to follow a more relaxed "Is this change backportable"
> Hyrum K. Wright writes:
> > I would add the further thought that as this is a "tool" rather than a
> > first-class component, I think we can play a little bit looser with
> > the rules.
> For what it's worth, I have a different opinion on this issue. Many of
> the modern DVCS's speak the Git fast-import protocol: See
> hg-fast-import or even BzrFastImport for example  . Even for
> those that don't, backing up a repository is as simple as tar'ing up a
> local checkout. It's a problem in the case of many centralized
> versioning systems, but there are third-party scripts to even get the
> data out of Perforce .
> Agreed, these modules should not be part of the core. However, in the
> case of Subversion, there absolutely NO way to get/ back up the
> revision history data* .
> Getting it out in a version-control
> independent format is a secondary challenge- the primary challenge is
> to get the data out in /any/ format. We're currently building a module
> that'll assist the second task- the infrastructure is already in
> vcs-svn/ in Git 1.7.3. I'll propose to merge /that/ into the
> Subversion trunk as a tool when it's ready, however svnrdump should be
> part of core.
> Even if you don't agree with the above and claim that `svnadmin
> (dump|load)` fits the bill, svnrdump can provide the same
> functionality- it can do what svnadmin can, only faster. There's been
> some speculation about getting svnrdump merged into svnadmin, but
> let's not get into that right now.
> As I see it, the reason we should have svnrdump in trunk is to build
> it and distribute it as a part of core Subversion: to enable people to
> get access to their own history, and to encourage them write
> additional tools on top of it.
I agree that svnrdump does something very useful and that it belongs in
Subversion. But I'm not sure whether it's mature enough today to belong
svnrdump is still young (less than, how much, 6 months old?). The code
still needs a bit of cleanup to remove rough edges (e.g., the most
recent one I recall is pool usage), and hasn't been tested widely. Yet,
svnrdump is in subversion/ and distributed as part of the core, while
svnmucc --- with 5 years of core developers' support under its belt ---
doesn't get built by 'make' by default.
Just to repeat: it's not a question of 'whether' svnrdump belongs in
subversion/svnrdump/, it's a question of whether it belongs there right now.
> -- Ram
> : http://github.com/artagnon/svnrdump
> : http://mercurial.selenic.com/wiki/FastImportExtension
> : http://wiki.bazaar.canonical.com/BzrFastImport
> : http://repo.or.cz/w/git.git?a=blob_plain;f=contrib/fast-import/git-p4;hb=maint
> : There's a Subversion equivalent of the git-p4 script called
> git-svn. It's a long, ugly, unmaintainable 5000-line Perl script
> * I suppose it's worth mentioning svnsync here although it takes years
> to finish and eats up eons of disk space. Mirroring an entire
> repository is NOT the way to get the data of a centralized
> versioining system- it was not designed to be used that way.
Received on 2010-09-25 14:48:13 CEST