Hi, Daniel Shahaf writes: > I agree that svnrdump does something very useful and that it belongs in > Subversion. But I'm not sure whether it's mature enough today to belong > in subversion/svnrdump/. > > svnrdump is still young (less than, how much, 6 months old?). The code > still needs a bit of cleanup to remove rough edges (e.g., the most > recent one I recall is pool usage), and hasn't been tested widely. Yet, > svnrdump is in subversion/ and distributed as part of the core, while > svnmucc --- with 5 years of core developers' support under its belt --- > doesn't get built by 'make' by default.
Less than 6 months, and I'm not a very experienced developer. The code in dump_editor definitely needs a little cleanup. Except for a few tests, it passes the complete svnsync testssuite. Ofcourse it's not perfect. By the time 1.7 is released, it'll probably be better than what it is now. I have no interest in politics, and I don't want to speculate why svnmucc isn't built by `make` by default. I would like to keep this discussion focused purely on the benefits and trade-offs of including svnrdump in subversion/svnrdump. If the discussion deviates from this, I would NOT like to be included in it- I'm a just a new partial committer and I don't know how your organization works. > Just to repeat: it's not a question of 'whether' svnrdump belongs in > subversion/svnrdump/, it's a question of whether it belongs there right now. As far as I'm concerned, development will happily chug along and whoever wants to use svnrdump will use it- the out-of-tree build will build against both Subversion 1.6 and Subversion 1.7 nicely and everyone's happy. The major downside of including svnrdump now is that users might complain that it doesn't work and will file some bugs. However, being a simple client-side utility, I doubt it'll cause any major catastrophies, even if it's used in production. The benefit is that it'll get more exposure- developers will find out about it and start writing tools that use it earlier. They will eventually discover more bugs and file them which will speed up its development. This is not speculation- the Git tool is almost ready, and will certainly be merged within the next couple of months. There are some projects using rsvndump- they will also benefit immediately. Ofcourse I understand that having authored svnrdump, it's possible that my personal interests have clouded my judgement. I've kept this in mind, and tried to be as unbiased as possible. I'll appeal to everyone else to do the same- do what you think is in the best interest of the greater good. -- Ram
