automatically remove "empty" commits mergeinfo properties

rengels
rengels
We have a problem when using the re-integrate command where it creates change revisions on files, but the only difference is in the mergeinfo properties, not in the text. Is there any scripts/tool to remove any commits to a file that ONLY involve mergeinfo property changes in order to clean-up the repository? The change log is very difficult to review with these crazy changes... Thanks.

Last updated

orbrey
orbrey
It's possible but not very easy - I don't know of any scripts or tools that can do it, it's a matter of dumping all the revisions you want to keep then creating a new repository for them, then loading the dump into the new repository and using that instead of your current one. More detail here: [url]http://robmayhew.com/delete-parts-of-subversion-history/[/url] Hope that helps.
rengels
rengels
[QUOTE=orbrey;168867]It's possible but not very easy - I don't know of any scripts or tools that can do it, it's a matter of dumping all the revisions you want to keep then creating a new repository for them, then loading the dump into the new repository and using that instead of your current one. More detail here: [url]http://robmayhew.com/delete-parts-of-subversion-history/[/url] Hope that helps.[/QUOTE] That would be unworkable... What about changing the commit comments on those individual files to something like 'merginfo changes', but not affecting the files with actual text changes ?
orbrey
orbrey
That's also doable, but only one revision at a time. You need to rename the temp file for the pre-revprop-change hook script in the repository (to pre-revprop-change), then it's a matter of: svn propset -r N --revprop svn:log "new log message" URL Where N is the revision number, "new log message" is your new commit message and URL is the repository URL. More detail here: [url]http://subversion.apache.org/faq.html#change-log-msg[/url] Hope that's a bit more viable?
rengels
rengels
[QUOTE=orbrey;168869]That's also doable, but only one revision at a time. You need to rename the temp file for the pre-revprop-change hook script in the repository (to pre-revprop-change), then it's a matter of: svn propset -r N --revprop svn:log "new log message" URL Where N is the revision number, "new log message" is your new commit message and URL is the repository URL. More detail here: [url]http://subversion.apache.org/faq.html#change-log-msg[/url] Hope that's a bit more viable?[/QUOTE] well, the problem is that all of the commit - including the good ones - all use the same revision number when you do the re-integrate, so that doesn't look like it will work... seems the only options is to read the repository change log (directly somehow???) and remove any changes to files that have only changes to mergeinfo Why does subversion suck so much ??? This is basic stuff that everybody must use, why is it so hard ???
orbrey
orbrey
Well, what is it you're trying to do with the merge --re-integrate? It might be that there's a way to do whatever you need without losing the individual commit references.
rengels
rengels
[QUOTE=orbrey;168879]Well, what is it you're trying to do with the merge --re-integrate? It might be that there's a way to do whatever you need without losing the individual commit references.[/QUOTE] There is a good chance we/I am doing something wrong... The basic process is: assuming a branch 'trunk', we create a branch called 'bug', we are making changes and committing to 'bug', also we are continually using 'merge' to update 'bug' with any commits to 'trunk'. After 'bug' is complete, we use 'reintegrate' to move the committed changes in 'bug' back to trunk. After the re-integrate, the problem is that it shows many files changes in the commit that were not changed, except in their 'mergeinfo' properties. This makes it very difficult to determine the 'text changes' that were part of the reintegrate commit. Ideas ?
orbrey
orbrey
Well, it sounds like you could create a patch file from the bugfix branch and then apply that to the trunk? More detail on that here: [url]https://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/[/url] If you do that then you'll have the patch file handy that can be reviewed to see what's changed if need be, and you shouldn't lose any commit data that way either. Hope that helps?
rengels
rengels
[QUOTE=orbrey;168884]Well, it sounds like you could create a patch file from the bugfix branch and then apply that to the trunk? More detail on that here: [url]https://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/[/url] If you do that then you'll have the patch file handy that can be reviewed to see what's changed if need be, and you shouldn't lose any commit data that way either. Hope that helps?[/QUOTE] I don't understand. People have made multiple commits to the branch. How do I create a diff that is just the changes made, or do I merge from trunk to the branch (so its up-to-date with trunk), then create a diff of all changes between the branch and trunk ?
orbrey
orbrey
Hi there, That is what a patch file is - a list of the changes made :) You'd need to stop people committing to the bugfix branch before making the patch, but I'd assume if it was ready to merge then commits would have been stopped on there anyway? There's more information on the diff command (the one that's used to make the patch) here: [url]http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.diff.html[/url] Basically it's a case of making sure you've checked out the latest version of the bugfix branch, then in the root of the working copy run: svn diff --old path/to/trunk --new path/to/branch > bugfix_refnumber.diff or similar Then the patch can be applied to the trunk, with the following command run once again at the root: patch -p0 -i bugfix_refnumber.diff Hope that helps?

1-10 of 10

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.

Post a reply
2714 views