From users-return-21949-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Tue Aug 12 16:09:35 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 D9FFA11826 for ; Tue, 12 Aug 2014 16:09:35 +0000 (UTC) Received: (qmail 19979 invoked by uid 500); 12 Aug 2014 16:09:35 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 19950 invoked by uid 500); 12 Aug 2014 16:09:35 -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 19940 invoked by uid 99); 12 Aug 2014 16:09:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2014 16:09:35 +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.39.63.55] (HELO nm27-vm2.access.bullet.mail.gq1.yahoo.com) (216.39.63.55) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2014 16:09:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1407859743; bh=cgSOReGNBrO2UDCt/JYPXU2QDKF48TO9RfCS4Ek582M=; 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=C1rVRWnw6NY37mh7egWbnE/R59SstbJhQxnLvU+33cHlCD6LWEItQjNKqDmDAcPnMA+2x5Ayo+qV2RxmvyP2hwspAeYNDIWMGJyoK/uCXWidKHc4WpQ4f8O3xWN+RuOFKRdpKKxCiM2+WipmBY1U3JKVRvMRMcUz/PEmBTl0Z5PZV+UKLRO5u4FmV6tsiRBG4d3jurimEZOQfLdAbEc08reR/yBRvGNhKNextu0ec0bGK74gs5HdgCmK1aNILPR+me/ZDqkgSxKJyeu0NghE5HWpeBmT38h4EcDrDbZlx2YUfxKO5FhuUvOWXatBpjPu3yiB10f0/u4lNQLm67y/cQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=AQ8qGMoSzkLLP+vbVlKr0Sn8dyYcgkcIYXM6y5eBX/2oAervJ24/Jk2dExj3RKg473m00AXemzxXqHGdFdPQGROxJ/BE1Fc+NrbNfC9n7fNwi7oNwdM8Q9ts4E2og/UouByDyDYYfsv+O+S9shaNqFusQ5gYOllm6m9/gzB7RDc+JtrBjETZRbl8p6frQ/EYOpFsvQJynsG8JM8pV/wBsP/dbGzNCQkCedmKvAwWd46DurTI3Yl2JSdA6T++pNQiKBZNhS8b1eZAm8lwtV2IhLfJXC6t+eTrpdxGTQI1CMGi54YW8tRXhYFbS+2GlQFyXH8setVNocZxpdErhNCR4w==; Received: from [216.39.60.175] by nm27.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Aug 2014 16:09:03 -0000 Received: from [98.138.104.97] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Aug 2014 16:09:02 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 12 Aug 2014 16:09:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1407859742; bh=cgSOReGNBrO2UDCt/JYPXU2QDKF48TO9RfCS4Ek582M=; 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=Dd0Y5i9WEczL9IvFyhrsVzCJk5RokIunp3aVyBCGOIWPypa9yJZUKJyjKsMg885ioYL7LB7g5KGgveBuW5sz9F9jqF2fbMMsp7bPRe0WQizkkWNr3YxOfZZvbTyPhwqNt3pFvhPaJidd3Q2e9tKpP5luhheqXHH2/2diM9SOtOQ= X-Yahoo-Newman-Id: 657367.47453.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ExT0awcVM1lR1ALzncNYgMYCx7Tuu6Q5kgxfUmZWgKyAFLJ NByQyFwoPhZcvrJ6BhdIZw9IqihkfJieSVmxgJEt5QQD5ZhcX8qt1b.cnFid XIkxTwJNsLxeOAtpXdO6TA.d3Xf6EKyF1AmXR1RWUj9.IO57rYGS0lwUtZ48 VAFk.uLCf64LkcBuG_W28sozCXmxvgfLHOOIMRGoqmVDFWedFKKqr70ovCnU W7wyBnJOLuX9P1yeC7RCw97iOoA9hchyBTZC9g1oX_1ZWyNhzcViQjlV8rG5 aofuExBe3ymP0N_aHLMK5ZbKb3QgqlF7xcBregEqNrJ3q2BsqbvqlM06y7fk xi0hemMDzXegTUaQboBaiI9NSaoIwVTe3yYBOUVJKa9boeCMW0aZnqQS.7oO XrkTt0BndhGwx7JBkwR9aO89b9f8PsX98oWQGpOVL1lBnGLuXXpmMYgdJ79O GhftSLgJprMTbj4DH3Fc52zQh_m0_85l65d8dKVtDYp9WlPfMOOqD3AqvLYs ECUTBB1vSNSY4QO7ojARUbqdepqTEXfWGk52JFg-- X-Yahoo-SMTP: 0h0Q7euswBD_g.kcEqbzJWRFfrba801gq1M1 From: Alexey Neyman To: users@subversion.apache.org Cc: Branko =?utf-8?B?xIxpYmVq?= Subject: Re: unversioned properties: size limitations? Date: Tue, 12 Aug 2014 09:09 -0700 Message-ID: <2216339.b5395D2q09@mistral> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <53E9C5AB.4050300@wandisco.com> References: <1558311.G5QHO8vnTt@mistral> <2244488.54Lqkg3YKe@mistral> <53E9C5AB.4050300@wandisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart78217154.nGeFLXOBOG" Content-Transfer-Encoding: 7Bit X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --nextPart78217154.nGeFLXOBOG Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday, August 12, 2014 09:43:39 AM Branko =C4=8Cibej wrote: > On 12.08.2014 09:26, Alexey Neyman wrote: > > On Tuesday, August 12, 2014 08:33:06 AM Branko =C4=8Cibej wrote: > > > So why do you need the last-changed revision of the project direc= tory > > > stored in the header file? Are you distributing sources directly = from > > > the repository, or are you using that number to identify builds? = In > > > either case, there are better ways to do that. > >=20 > > Sometimes, yes. Not directly from a repository but engineers someti= mes > > release semi-official builds to customers. > >=20 > > I understand that is less than ideal way (not dealing with > > mixed-revision WCs, etc.). So, I am curious what are those better w= ays > > you mention? >=20 > I'm sort of assuming a defined build (or packaging) workflow. If you > have engineers mailing binaries from their mixed-revision development= > working copies to customers, all bets are off, since they might have > locally modified your version property. >=20 > One solution is to run "svnversion" as part of the package/build and > include the result in the build artefacts. Can't go into any more det= ail > than that, since I have no ides what your build system looks like. Th= is > won't always perfectly identify the configuration you're building, bu= t > at least it will give some indication of the state of the working cop= y, > and whether (oh horror) it includes local modifications. 1. svnversion reports the revision of the check-out, not the revision o= f the last=20 modification. 2. svnversion does not provide the $Date$ information. 3. svnversion won't report anything on 'svn export'-ed sources. All that would be handled if there were a way to modify a transaction b= eing committed :) > > - Second, some of the MIME types are text even though the MIME type= > > does not start with 'text/*'. "image/svg", "application/x-sh" and > > "application/xml" are a few most obvious examples that come to mind= . I > > don't know how to come up with an exhaustive list of such > > "text-despite-MIME-type" types. >=20 > Heh, tell me about it. Subversion has the same problem, and we still > haven't found a satisfactory solution for it. Well, if Subversion set an svn:binary to true/false just to report the = heuristics, in addition to=20 svn:mime-type, that would've helped somewhat. But Subversion heuristics= only runs on=20 newly added files. > So you really only have to add this property on added files, right? H= ave > you considered using auto-props? They don't currently give you exactl= y > the knob you need, because we don't have an auto-prop setting for "al= l > binary" or "all text" files, but maybe that could solve your problem.= No, it is also set on existing files as they're modified. > Especially now that, with 1.8, you can define auto-prop settings in t= he > repository and no longer need local configuration on every client. > (Caveat: you do need 1.8 clients.) Now you tell me about that. I am still trying to weed out 1.6 clients (= which break horribly by=20 nested 'svn mv')- since CentOS does not update the base version of the = packages during=20 the release lifetime, CentOS 6.x is stuck with Subversion 1.6. Thanks to WanDisco for providing the CentOS RPMs for Subversion 1.7/1.8= :) It would be nice if there were a 'start-access' script that is run on a= ny access to the=20 repository - that can be used to block such older clients from even acc= essing the=20 repository. Speaking of 'wish' items: - How hard would be to implement client-side hooks? I know TortoiseSVN = has them, but=20 they're local - and to be really useful, they need to be propagated fro= m the repository.=20 And it would be nice to have them supported by the default commandline = client. If they=20 were supported, the tasks like the ones described above could be relega= ted to the client=20 side, and the server-side hooks could then just reject the commit if th= e client failed to run=20 the script. - How hard would be to allow modifications to a transaction by pre-comm= it? If it is just the=20 issue of client-side caches going stale - can a "shadow transaction" be= created that=20 records all the modifications by the pre-commit script and then sends i= t back to the client=20 to apply to the WC? Regards, Alexey. --nextPart78217154.nGeFLXOBOG Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On = Tuesday, August 12, 2014 09:43:39 AM Branko =C4=8Cibej wrote:

>= ; On 12.08.2014 09:26, Alexey Neyman wrote:

>= ; > On Tuesday, August 12, 2014 08:33:06 AM Branko =C4=8Cibej wrote:=

>= ; > > So why do you need the last-changed revision of the project= directory

>= ; > > stored in the header file? Are you distributing sources dir= ectly from

>= ; > > the repository, or are you using that number to identify bu= ilds? In

>= ; > > either case, there are better ways to do that.

>= ; >

>= ; > Sometimes, yes. Not directly from a repository but engineers som= etimes

>= ; > release semi-official builds to customers.

>= ; >

>= ; > I understand that is less than ideal way (not dealing with

>= ; > mixed-revision WCs, etc.). So, I am curious what are those bette= r ways

>= ; > you mention?

>= ;

>= ; I'm sort of assuming a defined build (or packaging) workflow. If you<= /p>

>= ; have engineers mailing binaries from their mixed-revision development=

>= ; working copies to customers, all bets are off, since they might have<= /p>

>= ; locally modified your version property.

>= ;

>= ; One solution is to run "svnversion" as part of the package/= build and

>= ; include the result in the build artefacts. Can't go into any more det= ail

>= ; than that, since I have no ides what your build system looks like. Th= is

>= ; won't always perfectly identify the configuration you're building, bu= t

>= ; at least it will give some indication of the state of the working cop= y,

>= ; and whether (oh horror) it includes local modifications.

 

1. = svnversion reports the revision of the check-out, not the revision of t= he last modification.

 

2. = svnversion does not provide the $Date$ information.

 

3. = svnversion won't report anything on 'svn export'-ed sources.

 

All= that would be handled if there were a way to modify a transaction bein= g committed :)

 

>= ; > - Second, some of the MIME types are text even though the MIME t= ype

>= ; > does not start with 'text/*'. "image/svg", "appli= cation/x-sh" and

>= ; > "application/xml" are a few most obvious examples that= come to mind. I

>= ; > don't know how to come up with an exhaustive list of such

>= ; > "text-despite-MIME-type" types.

>= ;

>= ; Heh, tell me about it. Subversion has the same problem, and we still<= /p>

>= ; haven't found a satisfactory solution for it.

 

Wel= l, if Subversion set an svn:binary to true/false just to report the heu= ristics, in addition to svn:mime-type, that would've helped somewhat. B= ut Subversion heuristics only runs on newly added files.

 

>= ; So you really only have to add this property on added files, right? H= ave

>= ; you considered using auto-props? They don't currently give you exactl= y

>= ; the knob you need, because we don't have an auto-prop setting for &qu= ot;all

>= ; binary" or "all text" files, but maybe that could solv= e your problem.

 

No,= it is also set on existing files as they're modified.

 

>= ; Especially now that, with 1.8, you can define auto-prop settings in t= he

>= ; repository and no longer need local configuration on every client.

>= ; (Caveat: you do need 1.8 clients.)

 

Now= you tell me about that. I am still trying to weed out 1.6 clients (whi= ch break horribly by nested 'svn mv')- since CentOS does not update the= base version of the packages during the release lifetime, CentOS 6.x i= s stuck with Subversion 1.6.

 

Tha= nks to WanDisco for providing the CentOS RPMs for Subversion 1.7/1.8 :)=

 

It = would be nice if there were a 'start-access' script that is run on any = access to the repository - that can be used to block such older clients= from even accessing the repository.

 

Spe= aking of 'wish' items:

 

- H= ow hard would be to implement client-side hooks? I know TortoiseSVN has= them, but they're local - and to be really useful, they need to be pro= pagated from the repository. And it would be nice to have them supporte= d by the default commandline client. If they were supported, the tasks = like the ones described above could be relegated to the client side, an= d the server-side hooks could then just reject the commit if the client= failed to run the script.

 

- H= ow hard would be to allow modifications to a transaction by pre-commit?= If it is just the issue of client-side caches going stale - can a &quo= t;shadow transaction" be created that records all the modification= s by the pre-commit script and then sends it back to the client to appl= y to the WC?

 

 

Reg= ards,

Ale= xey.

 

 

 

--nextPart78217154.nGeFLXOBOG--