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

Re: Proposal: --no-props switch for 'log', 'st' and 'diff'

From: Neels Hofmeyr <neels_at_elego.de>
Date: Thu, 04 Sep 2008 04:24:51 +0200

Gunnar Dalsnes wrote:
> Yes I agree, propchanges in the log etc. is really annoying but I want
> go further: equally annoying is propchanges during merge\commit: I merge
> a revision and I get a bunch of unrelated propchanges in (to me)
> unrelated files and folders (typically propchange on some subfolders,
> sometimes propchange on the root folder and often propdelete on misc
> unrelated files\folders). Some of my colleges consequently revert\don't
> commit those changes, they didn't change those files\folders so I fully
> understand. But why is this internal information leaking out to the
> users? This is purely an internal "thing" and the server should do this
> automatically! When I merge some files in a folder I expect that when I
> commit that folder, all changes are included, but now I must always
> commit the whole tree to include those propchanges spread around
> everywhere. Not good. The correct thing to do would be to make this
> invisible on the client and have the server do it automatically.

Hi Gunnar,

properties are a generic tool; you can also create your own properties on
files and directories and version them. This generic tool is, sort of
additionally, used by subversion itself, "internally". That's the problem.

A better way to deal with the problem you and others described is to
identify those "internal" properties that cause the users trouble and
provide a choice to omit these in the output.

Now, you argue, showing these "internal" property changes should be off by
default; I agree. Let's see what the others think:

The argument in another branch of this thread is that svn:mergeinfo is in
particular an annoying property to "innocent" users. Mark Phippard wants to
stop using properties for merge info altogether, and Hyrum K. Wright says:

"
I'm currently investigating a generic '--ignore-prop' switch, initially for 'svn
st'. It is being written in such a way that we could easily alias
'--ignore-mergeinfo' or '--forget-merges' or
'--dont-get-in-my-way-i'm-trying-to-do-real-work' to mean '--ignore-prop
svn:mergeinfo'. I hope to have a proof-of-concept patch done in a few days.

-Hyrum
"

I guess any one of these should eventually be exactly what you need ...
coming soon.

Thanks for your input!

~Neels

(btw, let's rather continue replying on the *other* branches of this thread
instead of this one.)

> And
> showing svn:mergeinfo logs should default to off, making this initially
> invisible.
>
> Gunnar.
>
>> In using merge tracking with 1.5.x and other branches, I've
>> occasionally been
>> annoyed by the fact that mergeinfo mods can often overshadow the meat
>> of a
>> change. I'd like to add a '--no-props' flag to 'log', 'st', and 'diff'
>> which
>> would simply cause the subcommand to ignore property changes. It
>> wouldn't be
>> the default, but it would clean up output and make using merge
>> tracking a bit
>> easier.
>>
>> I envision '--no-props' to be an all-or-nothing measure, initially,
>> but we if
>> the demand was there, we could further expand it to '--without-prop
>> FOO' which
>> would only omit changes to property FOO.
>>
>> Thoughts?
>>
>> -Hyrum
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

-- 
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Received on 2008-09-04 04:25:41 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.