dann frazier <[EMAIL PROTECTED]> 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, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
