On Thu, Feb 5, 2009 at 3:36 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, Feb 05, 2009 at 03:17:12PM -0500, Mark Phippard wrote:
>> On Thu, Feb 5, 2009 at 11:52 AM, Jens-Heiner Rechtien
>> <Jens-Heiner.Rechtien_at_sun.com> wrote:
>>
>> >> I'd have advised you not to do that, but I am inclined to think it
>> >> will be OK. You are probably going to need to cleanup the branches
>> >> though, else the old mergeinfo is going to make its way back to trunk.
>> >
>> > Yes, currently we remove the all the mergeinfo on trunk which comes in
>> > due to reintegration. This way we hope to keep trunk clean.
>>
>> That is a little bit more worrisome. It could turn out to be fine
>> because you use a structured release engineering process and the
>> branching model you are using does not currently require this
>> information, but it does not feel right. At a minimum, you will lose
>> the log/blame -g feature as it needs to see the svn:mergeinfo
>> committed with the merge to know what was merged from where.
>>
>> I thought you did a one-time "after the fact" cleanup. This would not
>> have broken log/blame because the cleanup would have happened in a
>> different revision than the commit.
>
> Removing mergeinfo is starting to become a habit to hack around
> limitations of the tool, like repo-copies were for CVS.
>
> We do it in our own repo all the time.
I do not think that is entirely accurate. Prior to 1.5.5, svn cp WC
WC created mergeinfo and we had accumulated a lot of it on our
subtrees. So we decided to finally get rid of it and did in one
swoop. There were a few follow-up cases where users using pre-1.5.5
clients created more of this mergeinfo and it was removed.
> I did it recently for a file
> I removed by accident and then resurrected by copying it back from
> history on the same branch. The rationale behind removing the mergeinfo
> in that case was that Subversion cannot tell whether a copy is a merge
> (copy between branches) or not (copy within one branch), and we don't
> need intra-branch information in merge history.
It either had a valid reason or it didn't. If it didn't, or you are
not sure, then raise an issue on dev@ so we can decide if this is
another instance where we can stop creating mergeinfo. But I do not
believe with the current trunk or 1.5.5 there are any/many instances
where it is being created incorrectly anymore.
> In this thread, people have said they remove mergeinfo without
> giving reasons why, or giving reasons that do not make much sense
> to me (and if they don't make sense to me, I don't think they make
> sense to the majority of users out there).
I think in the pre-1.5.5 releases people have become accustomed to
removing it on subtrees. Really only the mergeinfo created by copy
should potentially be removed. The mergeinfo created by merges should
be left in-tact.
The main "problem" is that once mergeinfo exists, subsequent merges
have to update it to reflect the merge activity. This winds up
creating undesirable log activity. Most people decide to get rid of
the subtree mergeinfo to avoid this.
> If this habit is due to a limitation in Subversion, we had better
> document it. We need decent documentation about this in some prominent
> place which explains what is safe to do and what is not. If people are
> really going to do this (we can't really stop them), than they had
> better know what mergeinfo is safe to remove and what isn't.
>
> I'd like to read such a document anyway, I definitely need some
> education about this.
Have you not read Paul Burba's mergeinfo manifesto?
http://blogs.open.collab.net/svn/2008/05/subversion-15-1.html
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1109776
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-06 01:35:51 CET