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.
Received on 2010-09-25 08:31:46 CEST