[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Suggestion for SoC

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-04-24 14:13:56 CEST

On 4/24/06, David Anderson <david.anderson@calixo.net> wrote:
> Hi,
>
> * Stefan Küng <tortoisesvn@gmail.com> [2006-04-21 20:18:29]:
> > Since there's some discussion about what issues could be used for SoC,
> > I'd like to add one more:
> >
> > Issue #901 : http://subversion.tigris.org/issues/show_bug.cgi?id=901
> >
> > I think this issue is big enough to keep a student busy during the
> > summer, but still not so big or complicated that it couldn't be
> > finished. And it can be done in stages, which is nice because even if it
> > doesn't get finished the parts already done can be used.
>
> Thanks for suggesting this. I must say I have some reservations,
> simply because it seems like an extremely open-ended task: "Provide
> finer grained notification". Could the issue be specified more
> precisely, so that the task falls clearly in the SoC scope?

Well, this is what I was thinking of:

Currently, network transfers never have finer grained notification
than the file level. When transfers per file get longer (as in
minutes, maybe), it's hard to distinguish actual activity from endless
loops and application lockup.

So, what I was thinking about is to add window-level (as in svndiff
window) or block level (as in SVN__STREAM_BLOCK_SIZE) notifications to
all RA transfers. Meaning: commit, update, import, cat, diff, merge,
(what other functions do file transfers?)

> Other than that, I'm okay for adding this as a proposed SoC task.
> What do others think about the scope of the problem?

If there are other notification points to be added, I'd like them to
explicitly become part of the list above.

bye,

Erik.
Received on Mon Apr 24 14:14:28 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.