From users-return-21958-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Wed Aug 13 05:43:29 2014 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 826CE11311 for ; Wed, 13 Aug 2014 05:43:29 +0000 (UTC) Received: (qmail 71210 invoked by uid 500); 13 Aug 2014 05:43:24 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 71178 invoked by uid 500); 13 Aug 2014 05:43:24 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 71167 invoked by uid 99); 13 Aug 2014 05:43:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 05:43:23 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.109.114.233] (HELO nm11-vm10.access.bullet.mail.bf1.yahoo.com) (216.109.114.233) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 05:42:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1407908572; bh=gUbPg0YPtxdZRT1jTvRk+U3drn/+JbTyswZ8U4wNvDg=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DcE37NYzl5rtXpoKyt2kwaEtKFL9fS6QPpuQrUKE9wtD8TsUJbM1lQLj0HZyjn4sBA/Ufdw0QovlFzfa5qVYLVym/HA9edadlpWYe49ibXNvGqUi5zUoJaSWcmAdDf027pcoQUbyfFJGMidrmw/DWWBBh8/fU1ZmPr5PeC2tsF3C9hnTRqOpn+Y9LcdP5QTeqfbdlq9tGrQmf9CzqXD/me6rtEbS/lgwqoRteNaVGASDiv1hcHG7wDvexKj56w5x9oEQ7rSDVqpBAh+dM10jm7jh8u+i4CoCgqRANNLLz8WY0XSxRNDSUy/1ryFKIlSJg4QN7P+gniLoWC88YwBSNg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=FfAw4Q6pDw+Svkh5wvBP0frXMEld2bJYlTV5mpVz73UTgwXoGfv6idQb/3nhXgLK2relCXS44RyMNNiyjkuCaOWwe+qOJ/qYXUaQky1ff6KRasRV8Vz6cJQ4XZS2haoww4tt7WmRUxsVOi7Cbq6/QG+jE5TDWHXnLuDICGwre4H8VDWJcMePPQYAcN8lHjEaiBDG7FTata0gBTU8k1oEQjLNGRaDS4On5R5uK/26VJGyaX4OHjX67Fi7D4LrgBB/tcOin6oaKWLCuHK5Bjw0THMzwqf1RBbTJwDB1MRUE2NRDoGQnAq6Z7TkfoKXSIqdE2Rq9iqTGgHWR12OoBCW/Q==; Received: from [66.196.81.160] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2014 05:42:52 -0000 Received: from [98.138.226.243] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2014 05:42:52 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 13 Aug 2014 05:42:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1407908572; bh=gUbPg0YPtxdZRT1jTvRk+U3drn/+JbTyswZ8U4wNvDg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jJhLACw1nh1Ga+TWiSTt0IEDGB2uphYa+4WFuD/hOpdwbfgBqp3PSGibwLexQGVnX+7Tij4dC9RB0Wy/NM3eafYN3nh3Re4iJiRopOq11ISpZBg+cGhLSrclQ5TemBPEPYfmjS5KsIKmrUXmsAvM8wVbYEu8Nm7Z9V2TysssaMo= X-Yahoo-Newman-Id: 270086.80708.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _SQw7D0VM1n4incUHgSJP1MrU.d9rLQ227Sw_JVXtplWqeC MqO_DsDXMQjCTyhpCo2iv8ljGqlisMEmLtsx7sj25qUlqny7O4kmI9_JmC_z fpBo41XaeHKuzY5k04rlCF4o1DILvFVltHlRpEsWI6VMuPWCrSBPrXTXM9zT .eUirUsnCROpLfXpFxn1k1W1FbLB7o2BmAec9Au2TAL.5u5Nalbp3bX5jovE yo6JaCc8G.iMpbE_WjNwERz.tiYjRTbZsThM1LbYe7tjGDwfAZZvXmgjYe.M kSKKiQAsMQsyn3kKzznt4TAfqzGB2msq0gB9vhmTokRYgdJMcUsQgo2LMXXx .dOUQHXJMsnQyJX0AOjKudJ5f.rl13lEaZnLXnVt4IUICB8sPkd3GdXvwAGk kn4zAgTZvci.06uTokCN2h6jmnUbmDRZPMxYbSVdZF3oMdpmqRf3NJ1xUCI0 Ao0m5_QGhaxwJqIJL9pOiWMsxwyOiCz30p4vjPGXTuHWBOkjxdLxOWAcSBiF 4HvggNN1n5t8bnXf0jDeGcuOeJKGM57uC4SDzuw-- X-Yahoo-SMTP: 0h0Q7euswBD_g.kcEqbzJWRFfrba801gq1M1 From: Alexey Neyman To: users@subversion.apache.org Cc: Ben Reser , Branko =?utf-8?B?xIxpYmVq?= Subject: Re: unversioned properties: size limitations? Date: Tue, 12 Aug 2014 22:42:50 -0700 Message-ID: <4942754.iBS5zAKfY1@mistral> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <53EAF538.6030106@reser.org> References: <1558311.G5QHO8vnTt@mistral> <1950020.vKkXaN35JA@mistral> <53EAF538.6030106@reser.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart3180847.lep1QCv2iZ" Content-Transfer-Encoding: 7Bit X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --nextPart3180847.lep1QCv2iZ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, August 12, 2014 10:18:48 PM Ben Reser wrote: > On 8/12/14 7:02 PM, Alexey Neyman wrote: > > Isn't that the same kind of change that happened with version 1.5 and > > mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A > > capability reporting was added, and a server can check that only > > mergeinfo-capable clients can start a commit. Same here, if a repository > > administrator wants to have pre-commit scripts that modify a transaction, > > he'd better check the clients' ability to handle a change to be applied > > to WC in server's response. > > If a server admin changes a transaction and the commit came from an old > client then the working copy is potentially broken. If an old client > doesn't know about mergeinfo it doesn't have access to that new feature. > New clients lose awareness of any merges committed by the old clients but > neither side is really broken. You just may be inconvenienced when > merging. I think there's a huge difference there. I think this thread quickly turns into a discussion how to roll out a feature that's not going to be implemented in the foreseeable future. I still think there would be feasible ways: Leaving it up to repository admin's configuration of start-commit - which is no worse than the current behavior if that repository's pre-commit modifies a transaction. OR Rejecting modifications to a transaction if the transaction was originated by non-aware client. OR Rejecting to promote the transaction into the revision if it came from non-aware client and was modified by pre-commit. It is pointless to discuss which if these approaches is better and/or acceptable, though, unless there is a decision to implement this feature. Regards, Alexey --nextPart3180847.lep1QCv2iZ Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Tuesday, August 12, 2014 10:18:48 PM Ben Reser wrote:

> On 8/12/14 7:02 PM, Alexey Neyman wrote:

> > Isn't that the same kind of change that happened with version 1.5 and

> > mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A

> > capability reporting was added, and a server can check that only

> > mergeinfo-capable clients can start a commit. Same here, if a repository

> > administrator wants to have pre-commit scripts that modify a transaction,

> > he'd better check the clients' ability to handle a change to be applied

> > to WC in server's response.

>

> If a server admin changes a transaction and the commit came from an old

> client then the working copy is potentially broken. If an old client

> doesn't know about mergeinfo it doesn't have access to that new feature.

> New clients lose awareness of any merges committed by the old clients but

> neither side is really broken. You just may be inconvenienced when

> merging. I think there's a huge difference there.

 

I think this thread quickly turns into a discussion how to roll out a feature that's not going to be implemented in the foreseeable future. I still think there would be feasible ways:

 

Leaving it up to repository admin's configuration of start-commit - which is no worse than the current behavior if that repository's pre-commit modifies a transaction.

 

OR

 

Rejecting modifications to a transaction if the transaction was originated by non-aware client.

 

OR

 

Rejecting to promote the transaction into the revision if it came from non-aware client and was modified by pre-commit.

 

It is pointless to discuss which if these approaches is better and/or acceptable, though, unless there is a decision to implement this feature.

 

Regards,

Alexey

--nextPart3180847.lep1QCv2iZ--