From users-return-22062-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Fri Aug 29 22:41:06 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 0AC88111B6 for ; Fri, 29 Aug 2014 22:41:06 +0000 (UTC) Received: (qmail 56508 invoked by uid 500); 29 Aug 2014 22:41:05 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 56471 invoked by uid 500); 29 Aug 2014 22:41:05 -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 56454 invoked by uid 99); 29 Aug 2014 22:41:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 22:41:05 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of danellis10@gmail.com designates 74.125.82.180 as permitted sender) Received: from [74.125.82.180] (HELO mail-we0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 22:40:39 +0000 Received: by mail-we0-f180.google.com with SMTP id w61so2784231wes.25 for ; Fri, 29 Aug 2014 15:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=moGo3CABJG2nQRqCMuR7GF/Rjc7HaY5UKSZn7TJKfZk=; b=Ob7wRh5Zto7rm1GhTyVbMPoutw/Ep2MGqi0TyPEZspQz/jXQ/etbRT4sLWSfhqBGzf 47/gEm1U5Ovu70QQf9789af0BrDHz75ygz/rlXqgXiXpkgdT+4tMB6yP1vJcBne9Bvu8 QnnCrfK/ZXY5UJ0Ke0f04GF0685SVzw8SAJJx+y7apuvsVTZWzxnmpaKkArh7O1/ok1C 8kDHqa9HIpomaa7pax3uLFioz8WYi+Dg4TN/bSVCqBH//q0Vm8xe6Coa5w0bk3K03aHd Oje1gqZXQ1EeB8/dNd51azzKJkdreMEaPPsNvJMg+7CgbVqNjmarPkR3aKi2L92PSlLS jbJg== MIME-Version: 1.0 X-Received: by 10.194.122.6 with SMTP id lo6mr16531779wjb.17.1409352038625; Fri, 29 Aug 2014 15:40:38 -0700 (PDT) Received: by 10.194.13.42 with HTTP; Fri, 29 Aug 2014 15:40:38 -0700 (PDT) In-Reply-To: <20140829091416.GC31428@ted.stsp.name> References: <20140828212708.GB31428@ted.stsp.name> <20140829091416.GC31428@ted.stsp.name> Date: Fri, 29 Aug 2014 15:40:38 -0700 Message-ID: Subject: Re: svn merge --ignore-properties From: Dan Ellis To: Dan Ellis , Subversion Users Content-Type: multipart/alternative; boundary=089e0117643da035730501cc5712 X-Virus-Checked: Checked by ClamAV on apache.org --089e0117643da035730501cc5712 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 29, 2014 at 2:14 AM, Stefan Sperling wrote: > On Thu, Aug 28, 2014 at 02:55:57PM -0700, Dan Ellis wrote: > > > > > > > It sounds like if you'd be in less trouble if you could 'revert' > individual > > > property changes to the working copy's BASE state independently of the > > > textual > > > changes, perhaps as a batch operation. There's no technical reason why > the > > > conflict resolver couldn't be taught to make this easy but it's not > > > implemented > > > > > > > > > I just re-read this Stefan and think I get what you are referring to. > Are > > you suggesting an additional parameter(s) to resolve that would allow > > accepting of a specific property or properties as a whole instead of a > > whole file including properties? > > Yes. > > > Something like "svn resolve foo.c --accept working --properties-only"? > > That could work well. > > Yes, and it could also be dealt with at the interactive conflict prompt. > E.g. it could allow the user to say "resolve this property to theirs-full > and apply that resolution to any other conflicted properties with the > same name" which is currently not possible. > > The resolver will only deal with conflicted properties. > If you also want to keep non-conflicted properties unchanged by the > merge, then 'svn revert' could likewise be extended with an interface > to achieve that. > Does this need to go over to the dev list for other developers to review/comment on? Thanks, Dan --089e0117643da035730501cc5712 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 29, 2014 at 2:14 AM, Stefan Sperling = <stsp@elego.de>= ; wrote:
On Thu, Aug 28, 2014 at 02:5= 5:57PM -0700, Dan Ellis wrote:

> >
> > It sounds like if you'd be in less trouble if you could '= revert' individual
> > property changes to the working copy's BASE state independent= ly of the
> > textual
> > changes, perhaps as a batch operation. There's no technical r= eason why the
> > conflict resolver couldn't be taught to make this easy but it= 's not
> > implemented
> >
>
>
> I just re-read this Stefan and think I get what you are referring to.= =C2=A0 Are
> you suggesting an additional parameter(s) to resolve that would allow<= br> > accepting of a specific property or properties as a whole instead of a=
> whole file including properties?

Yes.

> Something like "svn resolve foo.c --accept working --properties-o= nly"?
>=C2=A0 That could work well.

Yes, and it could also be dealt with at the interactive conflict prom= pt.
E.g. it could allow the user to say "resolve this property to theirs-f= ull
and apply that resolution to any other conflicted properties with the
same name" which is currently not possible.

The resolver will only deal with conflicted properties.
If you also want to keep non-conflicted properties unchanged by the
merge, then 'svn revert' could likewise be extended with an interfa= ce
to achieve that.

Does this need to g= o over to the dev list for other developers to review/comment on?

Thanks,
Dan<= /div>
--089e0117643da035730501cc5712--