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.
Related
I know how to revert a single opened file. However sometimes I hit some issues where I have to revert all files attached in a single changelist or revert all open pending files (default CL or assigned CL) in a client. Is there any way to do that? I tried p4 revert -c <changelist> where has multiple pending files. It didn't work for me. It works if I mention ALL the file names.
For me the following worked as well
p4 revert //... : Revert every file you have open, in every one of your pending changelists, to its pre-opened state.
or
p4 revert -c default //... : Revert every file open in the default changelist to its pre-opened state
Taken from : p4 revert documentation
I bet you just need to provide a filespec, try p4 revert -c <changelist> //...
On linux
p4 opened | sed 's/#.*//g' | xargs -n 1 p4 revert
Slight updated in the answer of #Talespin_Kit
Below one takes care of files that have spaces in their name
$p4 opened | sed 's/#.*//g' | xargs -n 1 p4 -d '\n' revert
When I try to run the command from the accepted answer
p4 revert -c <<changelist>>
I get the error:
Usage: revert [ -a -n -k -w -c changelist# -C client ] [--remote=rmt]
files... Missing/wrong number of arguments.
What I had to do was add the file name at the end of the command like so
p4 revert -c <<changelist>> //depot/folder/folder/file.txt
I have looked at different ways of doing this using diff. The first option I tried is:
p4 diff -sa
Opened files that are different from the revision in the depot, or missing.
Initially I figured that this was a file with write permission bit set that did not exist in the depot. However, I have since learned p4 doesn't use mode bits to track opened/unopened states as I first thought.
Next I figured this option would work:
p4 diff -sl
Every unopened file, along with the status of 'same', 'diff' or 'missin' as compared to its revision in the depot.
This would be okay, except "unopened" is not inclusive of "untracked" files. Although, when I ran this, it produced something quite different that contradicts the documentation; it output pretty much everything that was tracked, but also output everything that wasn't tracked, but flagged them as 'same'. Maybe this means that it hasn't been added and doesn't exist in the depot, so the client is the same as the depot...? In my SVN biased opinion, a rather pointless option.
Then there is the 'opened' option. But this does exactly that. It lists all the files in the depot that have been opened on the client; so not the files modified on the client not yet added.
So is there an option I am missing somewhere, that will provide some valuable answer, like SVN and CVS are able to do with one simple command?
$ svn status
A added
M modified
R deleted
? untracked
L locked
C conflict
Or:
$ cvs -q up -Pd
Okay, looking around and playing with the 'add' command, it seems that a read-only add will output successful message if the file is not currently controlled:
$ p4 add -n -f somefile
//source/somefile#1 - opened for add
I applied this to the following command and pretty much get what I need:
$ find . -type f | while read f ; do p4 add -f -n "$f" | grep -e '- opened for add' >/dev/null && echo "A $f"; done
A ./somefile
Or if you're not bothered about local paths:
$ find . -type f | xargs -l1 p4 add -f -n | grep -e '- opened for add'
//source/somefile#1 - opened for add
Well, there exists "p4 status", which is very similar in both purpose and behavior to "svn status".
For more ideas, see: http://answers.perforce.com/articles/KB_Article/Working-Disconnected-From-The-Perforce-Server
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 +++
When I check out a file with git checkout $commit $filename and I forget $commit but still remember $filename, how do I find out what $commit was?
First a non-git answer. Check your shell command history. Well, if you didn't use a shell with command history then you don't...
The git answer. You generally cannot find THE $commit. Generally the same contents might have been part of many commits and I don't think git keeps a log of what single file you have checked out (it keeps a log of previous values of HEAD)
Here is a brute force script git-find-by-contents. Call it with your $filename as parameter, and it will show you all commits where this file was included. As the name says
it searches by contents. So it will find files with any name, as long as the contents matches.
#! /bin/sh
tmpdir=/tmp/$(basename $0)
mkdir $tmpdir 2>/dev/null
rm $tmpdir/* 2>/dev/null
hash=$(git hash-object $1)
echo "finding $hash"
allrevs=$(git rev-list --all)
# well, nearly all revs, we could still check the log if we have
# dangling commits and we could include the index to be perfect...
for rev in $allrevs
do
git ls-tree --full-tree -r $rev >$tmpdir/$rev
done
cd $tmpdir
grep $hash *
rm -r $tmpdir
I would not be surprised if there is a more elegant way, but this has worked for me a couple of times in similar situations.
EDIT: a more techy version of the same problem appears here: Which commit has this blob?
I don't think you can. Git just loads that version of the file into the index and your working dir. There is no reference keeping track of what version it loaded
If this is something that you do often, you could write up a script that could do it using git diff --cached and march through all the commits that changed that file.
You can use
git log <filename>
to find out which commit you want to checkout
If you're lucky, you could maybe try a non-git way:
history | grep "git checkout.*filename"
Try this (untested ;):
$ for commit in $(git log --format=%h $filename); do
> if diff <(git show $commit:$filename) $filename >/dev/null; then
> echo $commit
> fi
> done
Simple and elegant:
$ git log -S"$(cat /path/to/file)"
Only works if the content is unique, then again that's the same for the hash-comparison answers that came before.
It also displays only the first version that matches, rather than all.
Here are the details of a script I polished up as the answer to a similar question, and here you can see it in action:
(source: adamspiers.org)
One of my colleagues has totally messed up the contents of a directory in our main CVS repository. I need to just revert the whole module to the state it was in at the end of last year. What's the CVS command to do this please?
He has added and removed hundreds of files, so a simple "copy over files from old checkout and commit" isn't enough.
I have RTFM and STFW, and I tried this:
cvs co modulename # Note no -P option
cvs up -jHEAD -jMAIN:2008-12-30 modulename
But that doesn't work - the new files he created get removed, but the old files and directories don't get resurrected. (I didn't commit it).
I can probably write a shell script for this, but surely this functionality must be in CVS already?
Update: Some clarifications:
I can get a local checkout of the module at a specific date. The question is how to get that back into CVS.
I do have backups, but the point using of a revision control system like CVS is that it's supposed to be easy to get any historical state. Next time something like this happens I may not be lucky enough to have backups (e.g. backups are daily, so I may lose up to a day's work).
I know that CVS is old, and we should move to something newer. But in a large team with a large number of CVS-based tools (checkout & build scripts, nightly build server, etc) the time cost of such a move is considerable. (Evaluation, updating scripts, testing, migration, training, lost developer time, maintaining both systems in parallel as CVS would still be needed for old branches). Hence this has to be planned & scheduled by management.
Update #2: I'm going to start a bounty on this. To qualify for the bounty you have to explain how to revert using normal CVS commands, not with a hacky shell script.
Update #3: The server is CVS 1.12.13. Access is via pserver. I can use the same version of CVS on a Linux PC, or the CVSNT 2.0.51d client on Windows.
Actually your initial approach was very close to the solution. The problem is, that joining date-based does not handle removed files and directories correctly. You need to set a tag to the code base you want to join first:
mkdir code_base1 && cd code_base1
cvs co -D "2008-12-30" modulename
cvs tag code_base_2008_12_30
Now do the join tag-based, subtracting all changes between now and 2008-12-30:
cd .. && mkdir code_base2 && cd code_base2
cvs co modulename
cvs update -d -j HEAD -j code_base_2008_12_30 # use -d to resurrect deleted directories
Compare the contents of code_base1 and code_base2. They should be identical except for the CVS meta information. Finally commit the code as it was on 2008-12-30 as new HEAD:
cvs commit -m "Revert all changes this year"
Note that tagging the code you wish to join like this will not work, because rtag also does not handle removed files and directories correctly, when using -D:
cvs rtag -D "2008-12-30" code_base_2008_12_30 modulename
There are several problems with CVS and you're hitting them with such a problem.
CVS is file-oriented, no concept of a changeset or snasphot. That means that changes such as the one you want to revert are a bit difficult to handle. Commits are atomic within a given directory, not outside.
Directories are not versioned. That means that empty directories will be deleted (if you update with -P) and that you have to specify -d to create them on checkout/update.
So, to answer your question, dates are probably the only way to deal with because you didn't use tags to create some poor man's version of changeset.
My comment about backups is that it may be easier to recover the whole repo from backups than try to correct things that CVS is not really good at.
I would encourage you -- but that is another subject -- to change version control as soon as you can. Trust me, I've been dealing with CVS for a long time within the FreeBSD project and learn very quickly how hateful CVS is... See here for some of my views on version control software.
I believe your second command should also be a checkout, rather than an update. I can't justify this with logic, since there is no logic in the world of CVS, but it has worked for me. Try this:
cvs co -P modulename
cvs co -P -jHEAD -jMAIN:2008-12-30 modulename
If you're reverting a branch other than HEAD, e.g. X, pass the -rX argument in both commands:
cvs co -P -rX modulename
cvs co -P -rX -jHEAD -jMAIN:2008-12-30 modulename
I'm still interested to know if there's an easier way. (There must surely be an easier way). What I ended up doing was, on a Linux PC using bash:
# Get woking copy we're going to change
cd ~/work
rm -rf modulename
cvs up -dP modulename
cd modulename
# Remove all files
find . -name CVS -prune -o -type f -print | xargs cvs rm -f
# Get the old revision
cd ~
mkdir scratch
cd scratch
cvs -q co -D 2008-12-31 modulename
cd modulename
# Copy everything to the working dir and do "cvs add" on it
find . -name CVS -prune -o -type f -print | \
xargs tar c | \
(cd ~/work/modulename && tar xv | \
xargs cvs add)
# Check everything is OK before we commit
cd ~/work/modulename
cvs -nq up
# it gave me an error on readme.txt because I'd deleted and then added it, so:
mv readme.txt x # save good rev
cvs add readme.txt # resurrect the bad rev
mv x readme.txt # clobber file with good rev
# Commit it
cvs commit -m "Revert all changes this year"
# Delete now-empty directories
cvs -q up -dP
# Double-check everything is back how it was
diff -ur -xCVS ~/scratch/modulename ~/work/modulename
Then I discovered that there were still differences - my colleague had added filenames containing spaces, which weren't deleted by the above process. I had to delete those separately. (I should have used find ... -print0 rather than -print, and passed the -0 argument to xargs. I just didn't realise there were files with spaces.)
You could look into cvsps. Google it.
Also, with quilt (or Andrew Morton's patchscripts, which is what quilt started out as) and cvsps, a very close approximation of changesets can be had.
see http://geocities.com/smcameron/cvs_changesets.html
Have you tried using the -d option? (build subdirectories)
As far as I can remember, it's implied for cvs co, but not for cvs up.
According to http://www.astro.ku.dk/~aake/MHD/docs/CVS.html, the following is what you need:
cvs update -D "30 Dec 2008 23:59"
Big problem, don't have full answer, just a tip on your scripting to deal with spaces in file names.
Instead of
find ... | xargs tar c - | ...
try putting
find ... | perl -e '#names = <>;' -e 'chomp #names;' -e 'system( "tar", "c", "-", #names);' | ...
that way, your archive creation (or similar operations) won't suffer from spaces in the names, the shell argv parsing gets skipped before tar is called.
One more thing, on the off chance it actually works: if there is a CVS to SVN utility, use it (I am assuming such a utility would pull deleted files from the "CVS attic"), and if it saves each moment in time as a project level checkpoint (since SVN does that, unlike CVS), use SVN to fetch the right moment in time. Lot of ifs...
If you or a colleague are comfortable with git, you could use git cvsimport to create a git repository mirroring the CVS repository. Reverting a commit/changeset in git is trivial (using git revert). You could then use git cvsexportcommit to send the revert commit to CVS.
This might all sound overly complicated, but in my experience git cvsimport and git cvsexportcommit work really well once you've got everything set up. You end up with all the power of git personally even though the project is still using CVS.
If you have a backup of your repository (the actual RCS files on the server, e.g. on tape) you could just restore that folder on the CVS server to the state it was before. Don't forget to stop the CVS server before doing this (and restart it afterwards).