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

From: Gunnar Dalsnes <hardon_at_online.no>
Date: Thu, 04 Sep 2008 23:41:47 +0200

Stefan Sperling wrote:

On Thu, Sep 04, 2008 at 01:42:30AM +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).
    

That's because mergeinfo is stored in properties.

That's the way it currently is. The only way of fixing that
would be to store mergeinfo somewhere else.
  

It's not fundamentally wrong to use props, as long as the handling is special:
-don't show mergeinfo propchanges on the client and in logs\diffs
-automatically include related mergeinfo propchanges when commiting\reverting\etc. the "real" files

Some of my colleges consequently revert\don't 
commit those changes, they didn't change those files\folders so I fully 
understand.
    

That's wrong. Your colleagues should _not_ omit mergeinfo property
changes from commits! If they omit these properties from commits,
they are not using Subversion as intended.

Users don't need to understand these properties. They just need to
know they exist, and that they should *always* commit any changes
to these properties which show up in their working copies alongside
their own changes.
  

Yes, lets put the responsibility on the individual user (famous last words?).
IMO, this is a blocker: if a user forget to commit some propchanges, we may be worse off than without merge tracking since we now rely on this to "just work" and don't review the merges as closely as before.

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.
    

That is a perfectly understandable point of view.
The tool should just work.

But in order to just work, the tool has to manage a certain amount
of information for you. If you don't let it do that, or if you interfere
with that, then you are not using the tool as intended.
  

When the tool rely on me to work correctly, then it hardly "just work".

Not good. The correct thing to do would be to make this 
invisible on the client and have the server do it automatically. And 
showing svn:mergeinfo logs should default to off, making this initially 
invisible.
    

This is a conundrum.

If we didn't show these properties by default, users would likely
end up not always committing changes the client has made to them.
  

Those propchanges should off course be committed automatically when i commit the merged file that caused the propchanges.

But for now, you will have to live with mergeinfo properties.
A lot of work has gone into the merge tracking functionality.
It's not a feature that is simple to implement. Changing something
as fundamental as the way mergeinfo is stored is certainly a good
amount of work.

So, I'm afraid I would not expect such a change to be made soon, if at all.
  

I'm sorry to hear that.

Gunnar.

Stefan



  

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org For additional commands, e-mail: dev-help@subversion.tigris.org Received on 2008-09-04 23:41:56 CEST