On Sun, Sep 07, 2008 at 03:19:05PM +0200, Vincent Lefevre wrote:
> On 2008-09-04 11:53:29 +0200, Stefan Sperling wrote:
> > On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
> > > 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.
>
> No, if Subversion modified svn:mergeinfo on *unrelated* files, his
> colleagues ignore these files because Subversion didn't behave as
> intended.
I agree that if totally unrelated files get their mergeinfo
modified, it's probably a bug.
IIRC there was no mention of that before in this thread, though.
As far as I understood, mergeinfo may pop up in unexpected
places sometimes, due to mergeinfo inheritance.
My understanding of this does not go very deep though. If you
or someone else can enlighten me, please do so :)
In fact, I may have to read pburba's blog post again to get up to speed:
http://www.collab.net/community/subversion/articles/merge-info.html
(I read it all once but forgot most of it again at this point.)
> > Users don't need to understand these properties.
>
> They don't need to understand them, but they currently are affected by
> them directly. If write access has been restricted on these unrelated
> files (see the other thread), this even means that some users can no
> longer commit!
That is indeed a good point. I'll try to find "the other thread"
to read up on this. BTW, it would be kind if you took the time to provide
a link (or at least a subject line) if you refer to other threads.
> > 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.
>
> This can also mean that the algorithm that modifies these properties
> is wrong.
Yes. It would help if you could also spell out the flaws you're seeing
in a manner that's suitable to pinpoint the exact problems in the
design/code.
> > By the way, I would argue that always committing the whole working
> > copy in one go is good practice anyway.
>
> I don't see this as good practice. The user may want to work on
> different sets of files.
... in different working copies. ;)
This is a bikeshed issue. Some people like working that way, some don't.
> > So, I'm afraid I would not expect such a change to be made soon, if
> > at all.
>
> How about an option to disable merge tracking?
For new projects: svnadmin create --pre-1.5-compatible /path/to/repos
Of course that does not help much with existing projects in 1.5 format.
I don't know if a knob to disable merge tracking has been suggested
before, but I don't think there would be a problem with a knob that
disables it. No idea now hard that would be to implement, though.
But I guess you'd mainly want to disable merge tracking to avoid running
into problems with the design or implementation, right? Apart from
the authz / svn:mergeinfo commit problem, what other problems are
you seeing?
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-07 21:44:18 CEST