Experimental Physics and
Industrial Control System

When going from svn to Git at aps,
some modules (not all) simply removed the svn keyboards with a shell script.
First the conversion svn -> git was done completely,
and everything was committed.

After that, in a different commit, all the (now useless) lines with keywords
had been removed.


The script may be used as inspiration:
https://github.com/BCDA-APS/conversions/blob/master/remove-svn-keywords.sh
(I put a copy here)

#!/bin/sh

shellfileOne=/tmp/$$svn-remove-keywordsOne.sh
shellfileAll=/tmp/$$svn-remove-keywordsAll.sh


cat <<EOF >$shellfileOne
#!/bin/sh
filename=\$1
git checkout "\$filename" &&
sed <"\$filename" \
  -e 's%Version:.*Revision%XXXXXXXXXXXXXXXXXX\$%' \
  -e 's%Modified [bB]y:.*Author%XXXXXXXXXXXXXXXXXX\$%' \
  -e 's%Last Modified:.*Date%XXXXXXXXXXXXXXXXXX\$%' \
  -e 's%HeadURL:.*URL%XXXXXXXXXXXXXXXXXX\$%' \

"\$filename.new" &&

if grep XXXXXXXXXXXXXXXXXX "\$filename.new" >/dev/null; then
	grep -v XXXXXXXXXXXXXXXXXX "\$filename.new" >"\$filename" &&
	git diff "\$filename"
fi
rm "\$filename.new"
EOF

chmod +x $shellfileAll $shellfileOne &&
$shellfileAll



On 07/04/16 12:44, Benjamin Franksen wrote:

Most of the files in base contain so called "keywords" such as
$Revision-Id$ inside comments. In released tar balls these are expanded
to a text like "Revision-Id:
[email protected]".

What is the rationale behind using these keywords? Ideally I would like
to get rid of them completely, see below for a rationale. Failing that,
is there a tool which reverts the expansion back to the raw keywords, so
that what I see is comparable to what I get with bzr branch?

My general gripe with these "keywords" is that they make comparisons
between different versions unnecessarily difficult especially if one of
them originates from a released tar ball, in which case the keywords
have been expanded (however this is done, apparently not using bzr since
the bzr-keywords plugin is completely broken) and I get thousands of
completely irrelevant differences which makes it quite hard to spot the
few relevant ones. This is especially important for users who import
base into a local repo (we use darcs) to track site specific changes
(fixes, configuration, experimental changes). The usual way to do this
cleanly is to create a vendor branch on which tar balls are imported,
plus the occasional upstream patch.

Cheers
Ben

References:

bzr keywords in source files Benjamin Franksen

Navigate by Date:

Prev: bzr keywords in source files Benjamin Franksen

Next: Build failed in Jenkins: epics-base-3.16-win32-test #38 APS Jenkins

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <2016>  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: bzr keywords in source files Benjamin Franksen

Next: Build failed in Jenkins: epics-base-3.16-win32-test #38 APS Jenkins

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <2016>  2017  2018  2019  2020  2021  2022  2023  2024