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

Re: svn commit: r1096619 - in /subversion/trunk/subversion/libsvn_wc: translate.c translate.h workqueue.c

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 25 Apr 2011 18:59:09 -0400

On Mon, Apr 25, 2011 at 18:51, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, Apr 25, 2011 at 18:01, Hyrum Wright <hwright_at_apache.org> wrote:
>> FYI: This has a slight alteration in the post-commit work queue item
>> skel.  If you've got un-cleaned up working copies laying around, this
>> may negatively impact them. :)
>>
>> (I went ahead with the commit, without a format bump, since work queue
>> items are short lived, and we don't make any promises of upgrading
>> them anyway.)
>
> That is NOT the policy that we've chosen in the past.
>
> Instead, we've extended a skel so that the code can determine which
> version you're using (eg. a new, optional element at the end). Or
> we've chosen two different OP names ("foo" and "foo-2") that dispatch
> to different skel parsers and call a common function.
>
> I disagree with changing the policy at this time, and would suggest
> finding a solution that will not break working copies that have stale
> work items in them.

For this particular change, the "old" skel had three items in it (path
and two flags). The "new" skel only has the path; any additional
elements in the skel will be ignored.

A new skel, processed by old code, would choke horribly... but the new
code can (seemingly) interpret old skels just fine.

Cheers,
-g
Received on 2011-04-26 00:59:36 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.