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
