automatically remove "empty" commits mergeinfo properties

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 8 years ago

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: http://robmayhew.com/delete-parts-of-subversion-history/  Hope that helps.

orbrey;168867It'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: http://robmayhew.com/delete-parts-of-subversion-history/    Hope that helps.

   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 ?

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: http://subversion.apache.org/faq.html#change-log-msg  Hope that's a bit more viable?

orbrey;168869That'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: http://subversion.apache.org/faq.html#change-log-msg    Hope that's a bit more viable?

   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 ???

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.

orbrey;168879Well, 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.

   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 ?

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: https://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/  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?

orbrey;168884Well, 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: https://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/    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?

   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 ?

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: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.diff.html  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?