I need to obtain the first revision number after given date?
For example, I need to know which is the first SVN revision number for the project Apache Hadoop after 2011-11-29.
I tried the command
svn log -r {2011-11-29} http://svn.apache.org/repos/asf/hadoop/common/trunk/
but in this case, there are no commit on 2011-11-29.
How can I get the first commit of 2011-11-29 or if not exist, after this date?
And finally, how can I only get the revision date from the SVN log?
Revisions in date period
Try
svn log -r {2011-11-01}:{2011-11-30} ## revision between dates
or
svn log -r {2011-11-01}:Head ## revisions from 2011-11-01 to head
or
svn log -r {2011-11-01}:Head -l5 ## Top 5 revisions from 2011-11-01 to head
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.html#svn.ref.svn.sw.revision
Get revision date from log
Try
svn.exe log --xml
And parse <logentry><date> tags with bash
Related
Question
Using the svn command line, I would like to find the last commit that touched a file. Here it is in pseudo-code:
svn log -v --search my-file.txt --first-match
What I have tried:
svn log -v --search my-file.txt -l 1
Unfortunately, this only searches the most recent commit. It doesn't return the first match.
svn log my-file.txt -v -l 1
Subversion complains that:
svn: E155010: The node 'C:\Users\my.user\Documents\SubversionSvn\MyDir\my-file.txt' was not found.
svn log svn://my.server.com/svn/path/to/my-file.txt
Svn complains that:
svn: E160013: File not found: revision 427, path '/svn/path/to/my-file.txt'
Just get the log of the file and limit it to the first (most recent) entry:
svn log my-file.txt -v -l 1
If the file was in your repository but was deleted, you'll need to pass a peg revision so SVN knows what file you're asking about:
svn log my-file.txt#3511 -v -l 1
Here, the peg revision is 3511 which is the last revision where the file existed before it was deleted from the repository. However you've already answered your question once you've found this number.
If the file was never in the repository (it isn't now, based on your errors), then this isn't a question that SVN can answer for you.
I use GUI , go to file on your comp, right click on file , TortoiseSVN > Diff with previous version
Link for command line
Can someone please help me understand why when switching branches with Git that the modified date in the Mac OS file system does not change? For example, I have a file in repo called test.txt that is part of both the Master and Test branches.
In the master branch I edit and commit the file and then switch to the Test branch. Since Git manipulates the file system, I would expect at that point that the date modified would change to the modified date of the version of the file in the active branch.
Your expectation is incorrect. Git doesn't record a file's timestamp at the time of commit.
Moreover, if the checkout operation requires Git to retrieve a different version of the file and copy it to your project's working tree, your operating system will update the timestamp of the file in the working tree to reflect the current date and time shown by your system clock.
Check things for yourself by performing the following experiment.
First set things up:
cd ~/Desktop
mkdir git_test
cd git_test
git init
Create a file, start tracking it and create a first commit (on master).
touch README.md
git add README.md
git commit -m "add README to project"
Now inspect the timestamp of the README.md file with
ls -la
Write that time down; in my case, the time is 19:00; let's call that "time1". At this stage, wait for at least 60 seconds. Then create and check out a new branch called other:
git checkout -b other
Edit README.md; for instance:
printf "This is the project's README\n" > README.md
Now stage the file and create a second commit (on other):
git add README.md
git commit -m "edit README"
Do ls -la again, and write down timestamp of README.md; in my case, the time is 19:02; let's call that "time2".
At this stage, the commit graph (try git log --graph --all --decorate) should look as follows:
* other, HEAD
|
* master
Now check out master again and inspect the timestamp of the README file in your working directory.
git checkout master
ls -la
Now, contrary to what you expect, the timestamp of README.md does not match time1, but the current clock time. Wait at least another 60 seconds before checking out other again and check the timestamp:
git checkout other
ls -la
Again in this case, contrary to what you expect, the timestamp of README.md does not match time2, but the current clock time.
Edit: Here's a shorter experiment demonstrating that Git doesn't bake the timestamp of a file into the SHA-1 hash of the corresponding blob.
printf "hello\n" > greetings.txt
git hash-object greetings.txt
Write down the hash value returned. Wait a bit.
touch greetings.txt
git hash-object greetings.txt
Even though touch greetings.txt changed the timestamp of greetings.txt in your filesystemm the hash value should be the same as the first time you invoked git hash-object.
There is a command for listing all files in a certain revision:
svn log --summarize -r119977:r119978
M /tradefed/DeathStarService/trunk/CMakeLists.txt
M /tradefed/DeathStarService/trunk/build.sh
...
There is a command for seeing difference for a file in a certain revision:
svn diff trunk/build.sh -r119977:r119978
Is there a command-line to see differences in all files in a certain revision?
Just omit the file specification from the diff command.
svn diff -r119977:r119978
I have updated cvs a few times and want to get one of the older versions, is it possible to get different versions of the same file? Or should it be only the latest checked in version?
Switch to a certain revision number: cvs update -r 1.42 myfile
Switch to a certain tag: cvs update -r mytag
Switch to a certain date: cvs update -D 'last friday 12:00 PST'
If you haven't already checked out some version, you can pass -r or -D directly to cvs checkout.
These all switch your working copy to the revision or date you specified (this is called a “sticky tag”). To go back to the head revision, issue cvs update -A.
You can also retrieve a specific revision into a different file with the -p option: cvs update -p -r 1.42 myfile >myfile-1.42. This doesn't touch your working copy of myfile.
Yes - in the lingo of CVS it sounds like you have committed several versions (to the repository) and now you want to get one of the previous revs back... so you will be updating your sandbox. If it's a particularly interesting rev, you might want to TAG it so you can find it again without having to use the rev number.
In either case you might run a cvs command like so:
cvs update -r 1.14 foo.java
cvs update -r spiffy_tag foo.java
But know that if you run either of those, you will have a "sticky tag" in your local copy and cannot commit back from there. (Run "cvs status foo.java" to see the sticky)... so if you want to work on that rev and tune it up, you might want to create a branch first... then if you run:
cvs update -r my-branch foo.java
you will be able to commit changes back to the repo.
Is it possible to checkout file of a specific revision using stcmd?
I want to checkout all (or some) history of a specific file.
Is it possible to checkout file of a specific revision using stcmd?
You can checkout a specific revision using the label as follows
"C:\Program Files\Borland\StarTeam Cross-Platform Client 2005 R2\stcmd" co -p "user:pwd#host:port/MyProject/view_r1/" -is -eol on -o -rp "D:\LocalDir" -cfgl "LABELNAME"
The history of a particular file in that label is gotten by
stcmd hist -p "user:pwd#host:port/MyProject/view_r1/" -cfgl "labelName" -is -rp "D:\LocalDir" FILENAME
stcmd.exe co has a -vn flag that allows you to specify a version number. This is the version number, not the DotNotation, so 1.15 would be version 16. This command:
stcmd.exe co -vn 1 -fp . -p "user:password#server:port/ProjectName/ViewName/FolderPath" file.ext
would get you the 1.0 of file.ext in the current directory. If you want to get the full history, you can parse the output of stcmd hist and figure out the current revision number, or you can just run the above stcmd co command with increasing version numbers from 1 until the result says "file.ext: skipped" instead of "file.ext: checked out" (the current version of stcmd does not error if the version number is too large to be valid). Remember to either delete the local file between calls or add the -o flag to overwrite it. I'd recommend deleting it - there have been issues with stcmd co and overwriting.
Note this will only get you the versions of the file on the current branch back to the 1.0 - you won't get any versions of the file from other branches. So if the current version is 1.5.2.1, you would be able to get 1.5.2.1, 1.5.2.0, 1.5, 1.4, 1.3, 1.2, 1.1, 1.0, but not 1.5.1.0.