You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by dann frazier <da...@hp.com> on 2007/02/05 19:35:24 UTC
pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
(I'm not subscribed to this list, please CC me on replies)
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.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398035
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400230
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406292
[2] -no_user_input, -p, -svn_username, -svn_password, -v & -wc
--
dann frazier | HP Open Source and Linux Organization
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
Posted by Karl Fogel <kf...@red-bean.com>.
"Ivan Zhakov" <ch...@gmail.com> writes:
> Looks reasonable for me. Also I propose change "_" separator symbol to "-".
> So "svn-intake" is my best :)
+1, I like it.
> And we could have "svn import --intake" (or "svn import --replace") in feature.
You mean, as a built-in feature of Subversion sometime in the future?
Maybe... but let's concentrate on the script for now. There are so
many new features going on at the moment :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
Posted by Ivan Zhakov <ch...@gmail.com>.
On 2/7/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Ivan Zhakov" <ch...@gmail.com> writes:
> > 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'.
>
> But then it would be impossible to tell whether one means "svn import"
> or "svn_import", in speech.
>
> Some synonyms for "import":
>
> give entrance to, give admittance to, give the entree; introduce,
> intromit; usher, admit, receive, import, bring in, open the door
> to, throw in, ingest, absorb, imbibe, inhale, breathe in; let in,
> take in, suck in, draw in; readmit, resorb, reabsorb; snuff up,
> swallow, ingurgitate; engulf, engorge; gulp; eat, drink
>
> Well, "svn_intromit" is probably a bit awkward, but "svn_ingest" might
> work. Or "svn_intake" -- Hmm, I actually kind of like that one.
>
Looks reasonable for me. Also I propose change "_" separator symbol to "-".
So "svn-intake" is my best :)
And we could have "svn import --intake" (or "svn import --replace") in feature.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
Posted by Karl Fogel <kf...@red-bean.com>.
"Ivan Zhakov" <ch...@gmail.com> writes:
> 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'.
But then it would be impossible to tell whether one means "svn import"
or "svn_import", in speech.
Some synonyms for "import":
give entrance to, give admittance to, give the entree; introduce,
intromit; usher, admit, receive, import, bring in, open the door
to, throw in, ingest, absorb, imbibe, inhale, breathe in; let in,
take in, suck in, draw in; readmit, resorb, reabsorb; snuff up,
swallow, ingurgitate; engulf, engorge; gulp; eat, drink
Well, "svn_intromit" is probably a bit awkward, but "svn_ingest" might
work. Or "svn_intake" -- Hmm, I actually kind of like that one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
Posted by Ivan Zhakov <ch...@gmail.com>.
On 2/7/07, Karl Fogel <kf...@red-bean.com> wrote:
> dann frazier <da...@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
Re: pysvn_load_dirs: a freely redistributable implementation of svn_load_dirs
Posted by Karl Fogel <kf...@red-bean.com>.
dann frazier <da...@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