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.
> 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.
> But why is this internal information leaking out to the
> users? This is purely an internal "thing" and the server should do this
> automatically!
Well, "the server should do this automatically" may be easier said
than done. If there was no reason for client-side state information
about mergeinfo, we would not have it in the first place.
> 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.
You don't delete your .svn directories either, even though you
can see them in the filesystem, right?
By the way, I would argue that always committing the whole working
copy in one go is good practice anyway.
If you have one set of changes in one part of your working copy and
another unrelated set of changes in another, why not organise your
work so that each set of related changes sits in their own working copy?
If your working copies are so large that you run out of disk
when creating a few of them, either get more disk space or
use sparse checkouts to reduce the size of your working copies.
> 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.
And then these users would starting complaining when merge tracking
fails to work.
But on the other hand I agree with your point that presenting merge
tracking data to users can be irritating.
I would not object to not using properties to store mergeinfo
if we can come up with a better way of storing it.
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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-04 11:52:49 CEST