Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: design document

subversion
Discussion topic

Back to topic list

Re: design document

Author cmpilato
Full name C. Michael Pilato
Date 2009-05-28 05:58:27 PDT
Message Stefan Sperling wrote:
> 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.ti​gris.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.

When I rewrote the commit driving code a long time ago, I anticipated the
need to handle commits to multiple repositories. The code may have gone a
bit stale, but the logic that harvests "committables" stores those items in
a hash that was designed to be primarily keyed on some unique repository
attribute (UUID, repos URL, or something). Of course, I think this was back
before we stored such things in our working copy, so I used a single static
key for that hash for the time being. But I still hold some hope that that
code can be revived and massaged into doing what is expected.

--
C. Michael Pilato <cmpilato at collab dot net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Attachments

« Previous message in topic | 6 of 16 | Next message in topic »

Messages

Show all messages in topic

design document yellowflying HuiHuang 2009-05-26 17:32:59 PDT
     Re: design document brane Branko Cibej 2009-05-27 06:21:44 PDT
         Re: design document stsp Stefan Sperling 2009-05-27 07:10:50 PDT
             Re: design document brane Branko Cibej 2009-05-28 00:46:18 PDT
                 Re: design document stsp Stefan Sperling 2009-05-28 04:50:58 PDT
                     Re: design document cmpilato C. Michael Pilato 2009-05-28 05:58:27 PDT
                         Re: design document stsp Stefan Sperling 2009-05-28 06:25:37 PDT
                             Re: design document cmpilato C. Michael Pilato 2009-05-28 07:23:21 PDT
                                 Re: design document stsp Stefan Sperling 2009-05-28 10:27:20 PDT
     Re: design document stsp Stefan Sperling 2009-05-27 07:32:39 PDT
     Re: design document yellowflying HuiHuang 2009-05-28 20:36:34 PDT
         Re: design document cmpilato C. Michael Pilato 2009-05-29 06:32:00 PDT
             Re: design document hwright Hyrum K. Wright 2009-05-29 06:40:56 PDT
                 Re: design document stsp Stefan Sperling 2009-05-29 07:40:33 PDT
     Re: design document yellowflying HuiHuang 2009-05-30 03:44:58 PDT
         Re: design document hwright Hyrum K. Wright 2009-05-30 07:00:38 PDT
Messages per page: