[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: place of svnrdump (was: Re: svnmucc multiline property issue)

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Mon, 27 Sep 2010 21:47:48 +0530

Hi Stefan,

Stefan Sperling writes:
> > "tools" and "subversion" are merely directory names. All I'm saying is
> > this: I don't want packaging/ distribution overheads for such a simple
> > package; users should be able to use whatever Subversion-interop tools
> > that other developers build by just having Subversion installed.
>
> There are many interoperability tools that are built on top of Subversion,
> and they're hosted as independent projects. By the above logic, we'd have to
> ship all those, and host them in our repository.

No. That's what I tried to point out in my email: the interop software
are "tools" like fast-import for hg and bzr, or even git-p4. That's
not what svnrdump is: svnrdump itself is *far* from being able to
provide interop. It's the *infrastructure* that's necessary for
interop tools to be built in a sane and maintainable manner.

If you're interested, check out git.git contrib/svn-fe leveraging the
infrastructure in vcs-svn/ to convert a Subverion dumpfile v2 into a
fast-import stream. It's VERY non-trivial.

> And what does "having Subversion installed" really mean?
> E.g. in the Linux world, the Subversion client/server packages are
> often separate, but not always. It's also possible for svnsync to
> live in a separate package from the svn binary.
> And if you install from source, you get whatever the "make install"
> target installs. And maybe you also run "make install-tools"? Who knows.
>
> The point is that this is something packagers need to worry about, not
> us. With a well-maintained distribution, you can also install svnmucc easily,
> just like you can install svn easily.
>
> Of course, svnrdump is more likely to end up being installed
> if it gets installed with the default "make install" target. But
> packagers might as well decide to split the result of "make install"
> into separate packages, and we can't do anything about it.
>
> In practice, I don't think any of this is very important.
> People who need the svnrdump tool will find it no matter what.
> Even if it was hosted as an entirely separate project.

I see- that's an interesting perspective.

> > Hm, I still don't understand this back-porting thing very well. Does
> > it mean that the svnrdump should always do what it currently does
> > functionally (plus anything additional)? Does it mean that any
> > improvements to the command-line UI should ensure that the current
> > command-line UI still works? Does it mean that the public API it
> > exposes through the headers should not break- do we instead have to
> > write corresponding '_2' functions?
>
> It means all of the above.
> We'll promise to support its current state until Subversion 2.0 breaks
> the world. That's why it's important to make sure everyone agrees that
> it is ready for that level of dedication. If it isn't, then we need to
> make sure our users understand that (by moving it to tools/, or by
> declaring it as experimental, or whatever).

Ah. Yeah, I think it's sane enough for this. I'll put in as much work
as I can before the release to fix perf issues. For now, it passes the
complete svnsync testsuite but for Issue #3717.

-- Ram
Received on 2010-09-27 18:20:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.