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

Re: design document

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 28 May 2009 12:50:52 +0100

On Thu, May 28, 2009 at 09:46:14AM +0200, Branko Cibej wrote:
> Stefan Sperling wrote:
> > On Wed, May 27, 2009 at 03:21:40PM +0200, Branko Cibej wrote:
> >> But why restrict to a single repsitory? I agree that one transaction per
> >> repository makes sense; however, I see no reason to not launch several
> >> commit transactions within one svn_client_commit. By the way, this would
> >> be an elegant solution for
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=1167
> >>
> >
> > Let's just go one step at a time, and focus on the "multiple working
> > copies" issue first. Once that is solved, we can easily extend it
> > to "multiple repositories".
> >
>
> I agree on the one-step-at-a-time approach, but I'm not sure about the
> "easily" unless the current design at least takes the next step into
> account.

Then please invest the time to suggest how the design can be made to
take the next step into account without major effort.

The focus right now is #2381, and not #1167. Making #1167 an extra
requirement creates extra work for Hui Huang. Having to solve an extra
problem that isn't on the charter of his gsoc project is not what gsoc
is about.

I am sure that it is possible to solve both issues eventually,
no matter what we do now. We can still bend the existing design later
if we find that it is insufficent to also satisfy #1167. But if you
have a clever idea that would already help #1167 a little, then please
tell it to us so we can discuss whether it's worth doing it.
But it must not create another huge pile of work, because there already
is a huge pile of work in front of Hui Huang.

Stefan
Received on 2009-05-28 13:51:24 CEST

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.