Developer fixes bug in a branch created from trunk. Then I test the branch and reintegrate back to trunk.
Lately I am also committing property changes. There are three files that I commit back to trunk over and over. I compared the content of the files in between revisions using svn and they are the same. Only some property changed.
Q1: is there any way so I would commit from command line only files that have M
in the first column only when I do svn st
?
Q2: Is there any way we can clean trunk or how to get rid of committing these three files over and over?
---- edit svn st gives me
M .
M controllers/database/udfs/searchForNameContSrch.sql
M controllers/eduMoodleInterface
M controllers/main
M controllers/teaching
M lib/utils/EduMail.php
M lib/views/learning/progress/reverse_template_converter.php
M pages/carer/carer_basepage.php
M pages/common/contact_list_detail_basepage.php
M pages/contact/contact_basepage.php
M pages/staff/staff_basepage.php
M pages/student/student_basepage.php
current solution is to revert the files that have M in the second column prior to commit. It works but is time consuming. Any other idea?
I'd be more inclined to figure out what's going on with the properties and solve that problem than try to just ignore them. That said, at the end of this answer, there's a one-liner that will speed up your revert process if you're on linux.
For the sake of this answer, I've set a property on one file ( window.c
) and modified another ( window.h
).
svn status
M window.c
M window.h
The main commands svn use for properties are:
svn propset answer 42 window.c
property 'answer' set on 'window.c'
Sets a propety 'answer' on file window.c to value 42. You're probably not wanting to use this.
svn proplist window.c
Properties on 'window.c':
svn:keywords
svn:eol-style
answer
Lists all of the properties (without values) on the file.
svn propget answer window.c
42
Gets the value of a specific property.
svn propedit answer window.c
Set new value for property 'answer' on 'window.c'
Opens up an editor (on my machine it's nano of all things) and lets you edit the property, then sets it on the given file.
svn propdel answer window.c
property 'answer' deleted from 'window.c'.
Deletes the specified property (this probably won't resolve your problem, my guess).
You can also do the svn diff
to find out which property is different:
svn diff window.c
Index: window.c
===================================================================
--- window.c (revision 35712)
+++ window.c (working copy)
Property changes on: window.c
___________________________________________________________________
Added: answer
## -0,0 +1 ##
+42
\ No newline at end of property
This basically says that the only change here is a property 'answer' has been added, with value 42 (and no newline).
So what I'd do
Start with svn diff
and find out what's changed:
svn diff controllers/database/udfs/searchForNameContSrch.sql
svn diff controllers/main
Have a google for the property that is changing and see if you can figure out what tool is setting it and turn it off.
You could try using svn propdelete
to ditch the properties, but I don't think that's going to help.
Failing that -- a quick revert script
Otherwise, if you're using linux, this one liner will revert the files that have property modifications, but not content modifications.
PLEASE TEST THIS ON NON-CRITICAL UPDATES THE FIRST TIME, YES?!?!?
svn status | grep "^ M" | sed "s/^.\{8\}//" | while read rv; do svn revert $rv; done
That is:
svn status
pipe it through grep and filter for ONLY lines that start with ' M' (so it will ignore 'MM' - important).
pipe it through sed and delete the first 8 characters (which are all the status columns before the file name).
pipe that into a loop and revert the given file name.
Here it is in action:
svn status
M window.c
M window.h
svn status | grep "^ M" | sed "s/^.\{8\}//" | while read rv; do svn revert $rv; done
Reverted 'window.c'
svn status
M window.h
You wrote that those properties change when you reintegrate back to trunk, so I guess the property that changes is svn:mergeinfo
, but you'd need to verify that.
Assuming the above, take a look at the following sources to understand what mergeinfo
is and why you really do want to commit those changes. Also, it is possible to clean up those properties and not make them reappear again if you stick to a stricter merging process - i.e. always run the merge on trunk/branch root directory. This way mergeinfo
will get recorded only on those directories, not on individual files. This has the benefit of not polluting your repo with mergeinfo
scattered around, and also makes your commit diffs cleaner.
Sources:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With