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 [1]. It'll
> be fairly trivial to write an svn18_compat module.
>
We'll be able to follow a more relaxed "Is this change backportable"
policy.
> 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 [2] [3]. 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 [4].
>
> 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* [5].
svnsync.
> 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
in subversion/svnrdump/.
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
>
> [1]: http://github.com/artagnon/svnrdump
> [2]: http://mercurial.selenic.com/wiki/FastImportExtension
> [3]: http://wiki.bazaar.canonical.com/BzrFastImport
> [4]: http://repo.or.cz/w/git.git?a=blob_plain;f=contrib/fast-import/git-p4;hb=maint
> [5]: There's a Subversion equivalent of the git-p4 script called
> git-svn. It's a long, ugly, unmaintainable 5000-line Perl script
> http://repo.or.cz/w/git.git?a=blob_plain;f=git-svn.perl
>
> * 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