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.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.
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.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2356125
Received on 2009-05-28 14:58:46 CEST