On Mon, Sep 27, 2010 at 07:48:06PM +0530, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Sperling writes:
> > I don't really mind where svnrdump lives.
> > The community is committed to supporting both the tools/ and subversion/
> > directories.
>
> "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.
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.
> > If backwards-compat rules automatically apply to everything below subversion/
> > (they do?), and that people feel that svnrdump may still change in
> > backwards-incompatible ways, we might as well decide to make the
> > subversion/svnrdump directory exempt from such guarantees during the
> > 1.7 release. It is a simple technical decision: Do we think that
> > the current feature set is worth supporting under our backwards-compat
> > rules? I do.
>
> 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).
> Hey, no hard feelings! I was merely citing how other version control
> systems make it easy for users to get access to their own history,
There are quite a few systems that make getting at history really hard.
But people only realise that when they're trying to migrate away to
something else :)
> and suggesting that Subversion should too.
Certainly!
> In the long-term, I think of svnrdump as just a simple dumping/
> loading "functionality" of Subversion: I don't really care *how* it's
> present; I just think it should be present: either as part of
> svnrdump, svnadmin, svnsync, or something else.
Yes, it's a valuable feature to have.
Stefan
Received on 2010-09-27 16:56:30 CEST