On 2/7/07, Karl Fogel <kfogel@red-bean.com> wrote:
> 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.
> >
[snip]
>
> 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.
>
I've an old idea that functionality of 'svn_load_dirs.pl' should just
extended behavior of 'svn import' command. So I propose name like
'svn_import'.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 7 09:04:11 2007