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

Re: taking temperature on externals

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 6 Apr 2009 18:25:42 +0200

On Mon, Apr 6, 2009 at 18:07, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Greg Stein wrote:
>> On Sat, Apr 4, 2009 at 23:40, Bert Huijben <rhuijben_at_sharpsvn.net> wrote:
>>> ...
>>> WC-NG should make it much easier to fix these scenarios as a working copy and all its externals will all be handled in the same database.
>>
>> Yup. I'm going to be doing a full revamp of the "what to commit?"
>> logic in wc-ng. Except for needing to maintain cmdline compatibility,
>> I see no reason that we cannot do multiple-repository commits, and to
>> commit properly/atomically across switched/external boundaries of
>> items from the same repos.
>
> The client code already theoretically (and perhaps only partially) supports
> this concept.  I rewrote it long ago to do commits based on item URL (as
> opposed to on-disk location), including the ability to sort things into
> different per-repository buckets.

There is a hash table of repositories, with the value listing each
item for that repository. However, the hash is keyed by a constant
string, and only that one entry is ever present. Some of the code
knows about the (1-item) hash table, and other parts of the code have
no idea what is going on.

There are about four different representations of "what to commit"
that are built during the commit process. Mapped from one to the other
to the other. Each with its own slightly different semantics and data
fields.

Ugh.

In the new code, finding "what to commit" will basically be a SELECT
statement from the database (all WORKING or ACTUAL nodes with a given
changelist value, then filtered by path).

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1562906
Received on 2009-04-06 18:26:06 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.