I have a legacy CVS repository which shall be migrated to Perforce.
For each module, I need to identify what branches exist in that module.
I just want a list of branch names, no tags.
It must be a command line tool, for scripting reasons.
For example (assuming there is a cvs-list-branches.sh script):
$ ./cvs-list-branches.sh module1
HEAD
dev_foobar
Release_1_2
Release_1_3
$
As a quick hack:) The same stands true for rlog.
cvs log -h | awk -F"[.:]" '/^\t/&&$(NF-1)==0{print $1}' | sort -u
Improved version as per bdevay, hiding irrelevant output and left-aligning the result:
cvs log -h 2>&1 | awk -F"[.:]" '/^\t/&&$(NF-1)==0{print $1}' | awk '{print $1}' | sort -u
You could simply parse log output of cvs log -h. For each file there will be a section named Symbolic names :. All tags listed there that have a revision number that contains a zero as the last but one digit are branches. E.g.:
$ cvs log -h
Rcs file : '/cvsroot/Module/File.pas,v'
Working file : 'File.pas'
Head revision : 1.1
Branch revision :
Locks : strict
Access :
Symbolic names :
1.1 : 'Release-1-0'
1.1.2.4 : 'Release-1-1'
1.1.0.2 : 'Maintenance-BRANCH'
Keyword substitution : 'kv'
Total revisions : 5
Selected revisions : 0
Description :
===============================================
In this example Maintenance-BRANCH is clearly a branch because its revision number is listed as 1.1.0.2. This is also sometimes called a magic branch revision number.
This will bring up tags too, but tags and branches are basically the same in CVS.
$cvs.exe rlog -h -l -b module1
I have a small collection of "handy" korn shell functions one of which fetches tags for a given file. I've made a quick attempt to adapt it to do what you want. It simply does some seding/greping of the (r)log output and lists versions which have ".0." in them (which indicates that it's a branch tag):
get_branch_tags()
{
typeset FILE_PATH=$1
TEMP_TAGS_INFO=/tmp/cvsinfo$$
/usr/local/bin/cvs rlog $FILE_PATH 1>${TEMP_TAGS_INFO} 2>/dev/null
TEMPTAGS=`sed -n '/symbolic names:/,/keyword substitution:/p' ${TEMP_TAGS_INFO} | grep "\.0\." | cut -d: -f1 | awk '{print $1}'`
TAGS=`echo $TEMPTAGS | tr ' ' '/'`
echo ${TAGS:-NONE}
rm -Rf $TEMP_TAGS_INFO 2>/dev/null 1>&2
}
with Wincvs (Gui client for windows) this is trivial, a right click will give you any branches and tags the files have.
Trough a shell you may use cvs log -h -l module.
Check for the very first file created and committed in the repository. Open the file in server which will list all the Tags and Branches together
Related
For eg:
In my nexus repo - Temp-releases, under com/abc/temp/trial-platform-rpm, I have various folders like
6.1.7.0.34
6.1.8.1.3
7.0.0.0.568
7.0.1.0.89
7.0.2.0.544
So my script will provide the first 4 digits (For eg: if the branch selected is 7.0.2.0) then from nexus, I need to find latest version for this release (which is 7.0.2.0.544)
INPUT
7.0.2.0
OUTPUT
7.0.2.0.544
Curl command is as below and provide the version in grep :
curl -s "https://nexussite/nexus/service/local/repositories/Core-deloy/content/com/abc/item/item-portal-rpm/maven-metadata.xml" | grep "." | sort | uniq | sed -e "s#\(.\)\(\)\(.\)\(\)\(.\)#\3#g"| grep 7.0.1.0 | tail -n1""
I'd need to see what has been changed between two directories which contain different version of a software sourcecode. While I have found a way to get a unique .diff file, how can I obtain a different file for each changed file in the two directories? I'd need this, as the "main" is about 6 MB and wanted some more handy thing.
I came around this problem too, so I ended up with some lines of a shell script. It takes three arguments: Source and destination directory (as used for diff) and a target folder (should exist) for the output.
It's a bit hacky, but maybe it would be useful for someone. So use with care, especially if your paths have special characters.
#!/bin/sh
DIFFARGS="-wb"
LANG=C
TARGET=$3
SRC=`echo $1 | sed -e 's/\//\\\\\\//g'`
DST=`echo $2 | sed -e 's/\//\\\\\\//g'`
if [ ! -d "$TARGET" ]; then
echo "'$TARGET' is not a directory." >&2
exit 1
fi
diff -rqN $DIFFARGS "$1" "$2" | sed "s/Files $SRC\/\(.*\?\) and $DST\/\(.*\?\) differ/\1/" | \
while read file
do
if [ ! -d "$TARGET/`dirname \"$file\"`" ]; then
mkdir -p "$TARGET/`dirname \"$file\"`"
fi
diff $DIFFARGS -N "$1/$file" "$2/$file" > "$TARGET"/"$file.diff"
done
if you want to compare source code it is better to commit it to a source vesioning program as "svn".
after you have done so. do a diff of your uploaded code and pipe it to file.diff
svn diff --old svn:url1 --new svn:url2 > file.diff
A bash for loop will work for you. The following will diff two directories with C source code and produce a separate diff for each file.
for FILE in $(find <FIRST_DIR> -name '*.[ch]'); do DIFF=<DIFF_DIR>/$(echo $FILE | grep -o '[-_a-zA-Z0-9.]*$').diff; diff -u $FILE <SECOND_DIR>/$FILE > $DIFF; done
Use the correct patch level for the lines starting with +++
svn offer lot of nice commands that make us able to know what is/did happening in our repository.
i am loking for a command that allows me to list the files that has been modified in a specific revisions (note a range, but a list of some specific revisions).
Exemple:
i'd like to know what are the files that have been modified in the revisions: 624 , 625, 630,631
but i'd like to groupe this by files (if a file has been modified in revision 624 and 630, i'd like it to be whan once)
svn diff --summarize .... can make this but for a range of revision, in my case the range is not possible to have.
PS:
i'm using redmine, so if the solution is there, it'd be nice also.
I don't know of any built-in way to do that in either Subversion or Redmine. I'd suggest writing a small script that repeatedly calls svn diff, and then processes the results.
As an example, here's a quick way to do it via the command line:
echo "255 318 319 320" | perl -p -e 's/ /\n/g' | xargs -I {} svn diff . --summarize -c {} | perl -p -e 's/^...\s*//' | sort | uniq
I have a patch file containing the output from git diff. I want to get a summary of all the files that, according to the patch file, have been added or modified. What command can I use to achieve this?
patchutils includes a lsdiff utility.
grep '+++' mydiff.patch seems to do the trick.
I can also use git diff --names-only which is probably the better approach.
grep '+++' mydiff.patch|perl -pe 's/\+\+\+ //g'
Details:
git diff produces output in the format
+++ b/file
So if you're using grep as Nathan suggested
grep '+++' mydiff.patch
You'll have the list of affected files, prepended by '+++ ' (3 plus signs and a space).
I often need to further process files and find it convenient to have one filename per line without anything else. This can be achieved with the following command, where perl/regex removes these plus signs and the space.
grep '+++' mydiff.patch|perl -pe 's/\+\+\+ //g'
For patch files generated with diff -Naur, the mydiff.patch file contains entries with filename and date ( is indicating the tabulator whitespace character)
+++ b/file<tab>2013-07-03 13:58:45.000000000 +0200
To extract the filenames for this, use
grep '+++' mydiff.patch|perl -pe 's/\+\+\+ (.*)\t.*/\1/g'
A decent way to do this is to use the --stat flag (or the --summary flag, if you need only new / deleted / renamed files for some reason).
Example:
git apply --stat peer.diff | awk '{ print $1 }' | sed '$d'
1-js/03-code-quality/index.md
CONTR.md
LICENSE.md
README.md
chat-app.readme.md
When you parse patches generated by git format-patch or others containing additional information about number of lines edited, it's crucial to search for ^+++ (at the start of the line) rather than just +++.
For example:
grep '^+++' *.patch | sed -e 's#+++ [ab]/##'
will output paths without a/ or b/ at the begin.
Let's say I checked in a changelist (in Perforce) with lots of files and I'd like to revert the entire changelist. Is there an easy way to "revert" the entire changelist in one fell swoop?
Currently I do something like this for each file in the changelist:
p4 sync //path/to/file#n (where "n" is the previous version of the file)
cp file file#n
p4 sync //path/to/file
p4 edit //path/to/file
cp file#n file
rm file#n
As you can imagine, this is quite cumbersome for a large changelist.
The posted answers provide correct answers, but note also that there is an actual menu option in P4V to do this for you now. It's in the latest 2008.2 Beta, and so should be officially released the the next week or three.
This link gives details.
It should be a lot simpler to use than the earlier answers, but I've not had the opportunity to try it myself yet.
Update This has now been fully released. See Perforce downloads.
This looks interesting. I haven't tried it personally.
The official answer from Perforce is at http://kb.perforce.com/UserTasks/ManagingFile..Changelists/RevertingSub..Changelists but the procedure is not all that much easier than the one you suggest. The script suggested by #ya23 looks better.
For some reason, the awk step does not work for me. I'm running from a Windows environment with emulated Unix command line tools. However, the following does work:
p4 describe -s [changelist_number] | grep // | sed "s/\.\.\. //" | sed "s/#.*//" | p4 -ztag -x - where | grep "... path " | sed "s/\.\.\. path //"
Here are possible locations to get Unix command line tools in a Windows environment:
http://sourceforge.net/projects/getgnuwin32/?source=typ_redirect
http://unxutils.sourceforge.net/
I have the same problem when I want to delete an entire changelist. so I use the following script (notice that it also deletes the changelist's shelve and the changelist itself. if you only want to revert, copy the relevant lines).
Also, make sure the sed applies to your version of p4.
#!/bin/bash
set -e
if [[ $# -ne 1 ]]; then
echo "usage: $(basename $0) changelist"
exit 1
fi
CHANGELIST=$1
#make sure changelist exist.
p4 describe -s $CHANGELIST > /dev/null # set -e will exit automatically if fails
p4 shelve -d -c $CHANGELIST 2> /dev/null || true # changelist can be shelveless
files_to_revert=$(p4 opened 2> /dev/null | grep "change $CHANGELIST" | sed "s/#.*//g")
if [[ -n "$files_to_revert" ]]; then
p4 revert $files_to_revert
fi
p4 change -d $CHANGELIST
The problem starts when you want to revert an entire changelist ( as a bulk ) that you've just submitted, and you need to start reverting files of #n-1 one by one fast ( because it's production ) ...
Wanted to support ya23's answer- the link of a Python script - it's really really easy to use ( and really easy to miss his comment )
You give it the revision you want to rollback, and it prepares everything automatically ( each file's #n-1 & merging and everything ) ... you just submit.