Pushmi support (was Re: Subversion Vision and Roadmap Proposal)

[Tim Starling <ts...@wikimedia.org>]

Stefan Sperling wrote:
> On Fri, Apr 09, 2010 at 12:13:56AM -0400, Greg Stein wrote:
>   
>> On Thu, Apr 8, 2010 at 22:55, Tim Starling <ts...@wikimedia.org> wrote:
>>     
>>> C. Michael Pilato wrote:
>>>       
>>>> We need to find a way to embrace and
>>>> empower would-be Subversion contributors.
>>>>         
>>> You could start by replying to their mailing list posts. Just a thought.
>>>       
>
> Tim, could you provide a link to whichever post(s) you had in mind?
> The lists have lots of traffic, and not everyone reads every post.
> It's possible that your posts were simply overlooked or arrived at
> a time where none of those reading your posts were able to reply.
> Thanks.
>
> (In general, when referring to other posts made to the list, providing
> a link to the archives is a very good idea...)
>   

That was my fourth post to this list, I was referring to the other
three, particularly:

<http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3C4BAA79DF.9040506@wikimedia.org%3E>

I could see that after being ignored on that issue, my only chance of
being heard would be to get to know the developers and then to take a
more personal approach. That's why I stayed on this list. Unfortunately
I haven't had much time to read it.

My problem is that Subversion is so slow, in terms of network
round-trips, that's it's virtually unusable in our application for tasks
like merging and annotating. Chia-liang Kao has done an awesome job of
providing a local cache layer for Subversion in first SVK and now
Pushmi. This would provide a good response to the many developers in our
community who are agitating for a switch to Git, except that due to a
minor deficit in Subversion itself, Pushmi is not usable for us. This
could be corrected with a patch to Subversion, possibly as short as a
few lines of code. I'm offerring to write the patch.

The Pushmi solution could then be documented on our wiki page on this topic:

http://www.mediawiki.org/wiki/Making_Subversion_faster

-- Tim Starling

RE: Pushmi support

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@hyrumwright.org] On Behalf
Of
> Hyrum K. Wright
> Sent: Friday, April 09, 2010 9:58 PM
> To: Stefan Sperling
> Cc: Philip Martin; Tim Starling; Greg Stein; Subversion Development
> Subject: Re: Pushmi support
> 
> The last thing I want to do is add more process (someones earlier
> comments
> about HACKING are quick illuminating), but it might be worth creating
a
> template for such a document and posting it somewhere.  I don't think
we
> need to go the full route of PEPs, but having some way to track design
> proposals with more finesse than the issue tracker would be nice.

Collabnet's TeamForge?

Re: Pushmi support

[Greg Stein <gs...@gmail.com>]

On Fri, Apr 9, 2010 at 16:58, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Fri, Apr 9, 2010 at 9:51 PM, Stefan Sperling <st...@elego.de> wrote:
>>
>> Or writing a design proposal, that clearly explains the intent
>> of the change, the reason why it's needed, the security implications,
>> how exactly the change will be implemented (e.g. where will the config
>> setting live that allows the new behaviour?), etc.
>> Something that helps people with loading the entire problem into
>> their brain quickly, so they can reason about it
>
> The last thing I want to do is add more process (someones earlier comments
> about HACKING are quick illuminating), but it might be worth creating a
> template for such a document and posting it somewhere.  I don't think we
> need to go the full route of PEPs, but having some way to track design
> proposals with more finesse than the issue tracker would be nice.

This is why patches are nice. Already have the format!


But yah... if it is going to be a lot of work, then discussion is at
least warranted. That's the best way to get a feeling for whether the
effort will be worth it.

In this case, I think the question "should I bother to work on this?"
was probably left hanging because the problem/solution was too vague
for people to definitively answer.

Cheers,
-g

Re: Pushmi support

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Fri, Apr 9, 2010 at 9:51 PM, Stefan Sperling <st...@elego.de> wrote:

> Or writing a design proposal, that clearly explains the intent
> of the change, the reason why it's needed, the security implications,
> how exactly the change will be implemented (e.g. where will the config
> setting live that allows the new behaviour?), etc.
> Something that helps people with loading the entire problem into
> their brain quickly, so they can reason about it
>

The last thing I want to do is add more process (someones earlier comments
about HACKING are quick illuminating), but it might be worth creating a
template for such a document and posting it somewhere.  I don't think we
need to go the full route of PEPs, but having some way to track design
proposals with more finesse than the issue tracker would be nice.

-Hyrum

Re: Pushmi support

[Stefan Sperling <st...@elego.de>]

On Fri, Apr 09, 2010 at 03:36:10PM +0100, Philip Martin wrote:
> Tim Starling <ts...@wikimedia.org> writes:
> 
> > That was my fourth post to this list, I was referring to the other
> > three, particularly:
> >
> > <http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3C4BAA79DF.9040506@wikimedia.org%3E>
> >
> > I could see that after being ignored on that issue, my only chance of
> > being heard would be to get to know the developers and then to take a
> > more personal approach. That's why I stayed on this list. Unfortunately
> > I haven't had much time to read it.
> 
> You were not exactly ignored, but asking for in-principle approval
> before submitting a patch is not the way the project usually works,

We do encourage people to write design proposals before writing
patches.

> particularly for something that could be a security issue.

Well, since we're well aware of the security implications
(Greg Hudons explains them well in
http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3C1269433056.7493.527.camel@ray%3E
) I'd say this isn't a problem. We just need to make sure to
make it secure by default.
I don't see a problem in principle with providing an optional
mechanism for users like Tim to pass credential information
via selected environment variables (like SSH_AUTH_SOCK) to
tools called by hook scripts.

> > could be corrected with a patch to Subversion, possibly as short as a
> > few lines of code. I'm offerring to write the patch.
> 
> Writing the patch would be a way forward.

Or writing a design proposal, that clearly explains the intent
of the change, the reason why it's needed, the security implications,
how exactly the change will be implemented (e.g. where will the config
setting live that allows the new behaviour?), etc.
Something that helps people with loading the entire problem into
their brain quickly, so they can reason about it.

Stefan

Re: Pushmi support

[Philip Martin <ph...@wandisco.com>]

Tim Starling <ts...@wikimedia.org> writes:

> That was my fourth post to this list, I was referring to the other
> three, particularly:
>
> <http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3C4BAA79DF.9040506@wikimedia.org%3E>
>
> I could see that after being ignored on that issue, my only chance of
> being heard would be to get to know the developers and then to take a
> more personal approach. That's why I stayed on this list. Unfortunately
> I haven't had much time to read it.

You were not exactly ignored, but asking for in-principle approval
before submitting a patch is not the way the project usually works,
particularly for something that could be a security issue.

[...]
> could be corrected with a patch to Subversion, possibly as short as a
> few lines of code. I'm offerring to write the patch.

Writing the patch would be a way forward.

-- 
Philip

Re: Pushmi support (was Re: Subversion Vision and Roadmap Proposal)

[Tim Starling <ts...@wikimedia.org>]

Alec Kloss wrote:
> On 2010-04-09 21:54, Tim Starling wrote:
> [chop]
>   
>> My problem is that Subversion is so slow, in terms of network
>> round-trips, that's it's virtually unusable in our application for tasks
>> like merging and annotating. Chia-liang Kao has done an awesome job of
>>     
> [chop]
>
> I assume you're talking about https mechanism.  Subversion is much
> faster with svn:// or svn+ssh://.
>   

We use svn+ssh. It's very slow. I can believe that https would be slower
still.

Obviously it depends on:
* The number of files in your working copy
* The number of revisions you're trying to work with
* The distance between you and the server

We have plenty of all three.

-- Tim Starling

Re: Pushmi support (was Re: Subversion Vision and Roadmap Proposal)

[Alec Kloss <al...@oracle.com>]

On 2010-04-09 21:54, Tim Starling wrote:
[chop]
> My problem is that Subversion is so slow, in terms of network
> round-trips, that's it's virtually unusable in our application for tasks
> like merging and annotating. Chia-liang Kao has done an awesome job of
[chop]

I assume you're talking about https mechanism.  Subversion is much
faster with svn:// or svn+ssh://.

-- 
Alec.Kloss@oracle.com			Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14