dann frazier <dannf@hp.com> writes:
> Due to licensing issues w/ svn_load_dirs[1], I have started a
> reimplementation of this tool, currently under the GPL license. This
> implementation is intended to become a drop-in replacement for
> svn_load_dirs, though it is currently missing some of its features[2] -
> not uncoincidentally the ones I never used in the original. I plan to
> increase compatability over time.
>
> http://free.linux.hp.com/~dannf/pysvn_load_dirs
>
> pysvn_load_dirs uses the pysvn module mostly because that's the
> one I'm most familiar with. Porting to the libsvn interface, at a
> glance, looks pretty straightforward.
>
> I'm interested in bug reports and, of course, patches :) I'm currently
> developing in non-public svn repository until I find a public place to
> host it.
I accidentally sent this reply to Peter Samuelson earlier, instead of
to you, because he forwarded your mail to us. Here it is again, this
time in the correct thread and with the right reply metadata:
----------------------------------------------------------------------
Can I make a suggestion? "svn_load_dirs" was never a very descriptive
name anyway, for a tool that essentially does what most people think
of as "vendor branches" (although some object to the latter term on
the grounds that often the source is not a vendor but another open
source project).
In any case, both in order to avoid identity confusion and to have a
better name, maybe you could name it something wholly new, and just
say in its documentation that it's intended as a drop-in replacement
for svn_load_dirs?
Possibilities: "sourcedrop", "svn_vbranch", "sidefork"... I dunno, I'm
just making stuff up, probably you can come up with something better.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 7 02:29:08 2007