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