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.
> 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 seems to be quite sane at the
moment, and I don't think backporting is an issue; I'm not very
experienced in this though, so I wouldn't take my own opinion too
seriously.
> > > 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.
>
> It really doesn't matter. It's just the name of a directory and a set
> of promises we give to our users about backwards-compat.
> There's no need for hard feelings.
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, and
suggesting that Subversion should too.
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.
-- Ram
Received on 2010-09-27 16:20:07 CEST