> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: Thursday, September 30, 2010 8:24 AM
> To: users_at_subclipse.tigris.org
> Subject: Re: [Subclipse-users] Commit dialog - text vs property changes
>
> What do you mean by pre-commit reviews?
Before an engineer commits a change, we have a second engineer review
the changes with the author for correctness.
> Maybe you should use create
> patch? That shows the property changes in the content and might make
> it easier to sift through.
Thanks for the suggestion. We'll try this out to help focus our reviews
on our prop edits instead of having to sift through SVN-generated prop
edits too. Searching through the diff would save us a lot of clicking
vs the commit dialog. And we can just search for "Property changes on"
over and over again to skip over mergeinfo.
From our workflow perspective, we'll have to use the commit dialog for
text reviews (to provide context needed to understand the diff) and the
create patch feature for property reviews to filter out mergeinfo. It'd
be great to have a single tool to do thest things. If you see any Subclipse
enhancements which may smooth things out for us it'd be appreciated.
> I saw your post on the SVN users@ list and while I did not read it
> carefully, you are not experiencing anything that most other merge
> tracking users have not reported. You have to (or at least should)
> commit these mergeinfo changes with the content.
Yes, one point in that post was that SVN allows the user to omit mergeinfo
generated by the merge operation. I don't see a real benefit to allowing
this in the tool (maybe worth considering in SVN1.7), but to ensure no merge
info is lost in 1.6 we must enforce a policy. Essentially the same as you
suggest below, which is always merge from /trunk into /branches/branchN and
always commit from /branches/branchN.
> SVN 1.7 is going to reduce the noise.
That's good news. If you can point me to more info on the implementation
it'd be appreciated.
Also, just to get it off my chest :), my personal view is that property
changes by SVN, which the user is instructed not to edit (e.g. mergeinfo)
should never be viewable to the user. Maybe SVN should not stored it as
a property, given that SVN UI's want to display all properties regardless.
FWIW.
> In 1.6, the only way to reduce it is to eliminate
> nodes that have mergeinfo and try to get it consolidated at your
> project root. Then encourage users to do all merges and commits from
> the project root so that it does not come back.
Yes, this is also the only way I've found to reduce the noise in 1.6. But
IMO it's not good to delete mergeinfo simply because it causes noise during
a merge+commit. The reason we did the merge in the first place was to keep
track of the merge source/dest. That's a valid use case. The bug is the
noise, so the change should really be made to address the noise. It looks
like 1.7 will address this, which is good news for us. Thanks.
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2666689
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-09-30 22:00:17 CEST