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:
It's not fundamentally wrong to use props, as long as the handling is special: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.
-don't show mergeinfo propchanges on the client and in logs\diffs
-automatically include related mergeinfo propchanges when commiting\reverting\etc. the "real" files
Yes, lets put the responsibility on the individual user (famous last words?).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.
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 the tool rely on me to work correctly, then it hardly "just work".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.
Those propchanges should off course be committed automatically when i commit the merged file that caused the propchanges.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.
I'm sorry to hear that.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.
--------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.org Received on 2008-09-04 23:41:56 CESTStefan
This is an archived mail posted to the Subversion Dev mailing list.