[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: place of svnrdump (was: Re: svnmucc multiline property issue)

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Sat, 25 Sep 2010 19:15:16 +0530


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
Received on 2010-09-25 15:47:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.