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.
