Hi, 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. 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]. 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. -- 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.
