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

Re: buddy for two externals issues? -- was: Re: locking externals

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Sat, 11 Apr 2009 20:22:22 -0500

On Apr 11, 2009, at 6:12 PM, Neels Janosch Hofmeyr wrote:

> Stefan Sperling wrote:
>> On Sat, Apr 11, 2009 at 12:18:44PM -0400, Mark Phippard wrote:
>>> On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <neels_at_elego.de
>>> > wrote:
>>>> Neels Janosch Hofmeyr wrote:
>>>>> Right, if no-one speaks up this time, I'll make two new issues.
>>>> Buddy system!
>>>>
>>>> Does anyone agree that these two are good to be issues?
>>>>
>>>> #1 externals with a fixed revision aren't locked for commit as
>>>> long as
>>>> that fixed revision coincides with HEAD.
>>>>
>>>> #2 when a file-external with a fixed revision is modified, the next
>>>> update causes a conflict with the (unrelated) HEAD revision.
>>>>
>>>> I am attaching a shell script that makes both of them happen, for
>>>> both file-
>>>> and directory externals.
>>> I agree these would be good changes. I suspect they will be
>>> difficult
>>> to implement. AFAIK, svn does not always even know you are
>>> working in
>>> an external. Especially when we are talking about folders. For
>>> example, if you run commands like svn st from your project root,
>>> then
>>> it knows that those folders and items are externals. But if you run
>>> the command from a folder down within the external, it no longer
>>> knows
>>> this. The only way the command line will commit externals is to do
>>> this. So you'd have to ask the command line code to always walk the
>>> tree to the root of the WC so that it could then discover if an item
>>> is an external. That seems like a risky change for a small benefit.
>>>
>>> Ideally, and perhaps the new WC will allow this?, the WC would just
>>> know that these items are externals and could handle them
>>> differently.
>>
>> Since externals probably won't be easy to fix in 1.6.x, I'd say it
>> makes sense to make these fixes in wc-ng, hopefully released in
>> 1.7.x.
>
> If we adhere to the 6 months schedule, 1.7 is in June. That's
> roughly eight
> weeks from now :P

Huh? 1.6.0 shipped less than a month ago. Six months from March 20
is Sept. 20, not June. I'm personally planning and hoping to have wc-
ng code complete by the end of August, and hope to have wc-ng on trunk
usable as the default within a month (though that may be optimistic).

>> And I'd rather see yet another dev get accustomed to wc-ng code
>> instead of trying to fix things in the ever-so-broken old libsvn_wc.
>>
>> Stefan
>
> It seems that currently, pretty much anything I look at is said to
> be better
> with wc-ng. So far I always agreed, but it starts to feel a little
> eerie by
> now.

wc-ng is *not* a panacea, but the storage model is vastly superior to
what we've got now. For instance, each node (file, directory, etc)
will know to which repository it references, so an external is simply
a node which references a repository different from it's parent.
Pretty simple to represent, and it should be easy for somebody to come
along and write the higher-level piece which use that information.

> We should post a request that wc-ng should make it cheap to know
> whether any
> WC node is (part of) an external and whether that external has an
> explicit
> revision number pinned on it in its definition.
>
> BTW, do we have a wc-ng newsticker? ;)

I don't know about a newsticker ("new sticker" or "news ticker"? :P),
but it would be nice to have a place to collect these "oh, wc-ng will
fix that" issues that come up frequently. We've got a meta-issue in
the issue tracker, as well as notes/wc-ng-design. Perhaps one of
those will be suitable?

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1658959
Received on 2009-04-12 03:23:00 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.