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
