A commit in Subversion increments the revision number for all files by 1(correct me if i'm wrong). But when I look in Eclipse, I see that files have different revision numbers:
The revision number is behind the filename. Why is Eclipse showing different revision numbers for each file? I'm using the Subclipse plugin.
You are wrong in assuming that all files have the same revision number.
When committing some files the committed files all get a new revision number. This revision number is the next revision number for the repository used.
Now if you commit one file but not the other the first file gets a new number whereas the other file keeps the old number.
So in your image all files with the same revision number were committed at the dsame time. A higher revision number for a file means that this file was committed later than a file with a lower number.
So the displayed revision numbers are as expected.
Subversion working copies do not always correspond to any single
revision in the repository.
See "Mixed-revision working copies" SVNBook section.
Related
I have a project in Eclipse under SVN versioning.
Supposing the project is composed of two files A and B, I define the revision number of the project the newest revision between A and B. So if A has rev 10 and B rev 11 the revision of the project is 11.
How can I put the project revision number into the project files?
If I'm not wrong, SVN keyword expansion is not enough as it writes the revision number of the last change to each file and not to the "project"
There is no specific svn keywords or svn command to automatically add the HEAD revision in each file. But there is a svn command to retrieve this revision number. Then you have to develop additional tooling by yourself.
Here is an extract of http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html:
Where's $GlobalRev$?
New users are often confused by how the $Rev$ keyword works. Since the
repository has a single, globally increasing revision number, many
people assume that it is this number that is reflected by the $Rev$
keyword's value. But $Rev$ expands to show the last revision in which
the file changed, not the last revision to which it was updated.
Understanding this clears the confusion, but frustration often
remains—without the support of a Subversion keyword to do so, how can
you automatically get the global revision number into your files?
To do this, you need external processing. Subversion ships with a tool
called svnversion, which was designed for just this purpose. It crawls
your working copy and generates as output the revision(s) it finds.
You can use this program, plus some additional tooling, to embed that
revision information into your files. For more information on
svnversion, see the section called “svnversion—Subversion Working Copy
Version Info” in Chapter 9, Subversion Complete Reference.
CVS is showing multiple revisions numbers at the end of my file names. Any idea what is going on here and whether I should be worried?
I am not sure how do you sync your files with your CVS. In my case I do sync externally[meaning, not from eclipse] in such case you can select all your projects > Team [on right menu] > Disconnect >do not delete CVS metadata info in next window.
CVS (like RCS, but unlike many other systems like SVN and Git) tracks the revision history of each file independently. In SVN, for example, a given version number applies to the entire repository. In CVS, each file has its own independent history and current version number. Having different version numbers for different files is perfectly normal.
I'm just getting started with SVN after many years using CVS. As I understand it, the project revision number reflects the highest revision number of its contents.
As a test, I created a simple Java project and shared it using the 'multiple projects layout'. I notice that the decoration on the project is changed first (to rev12400) and then the contents (to rev12401). The project revision remains at 12400 which I don't understand. A refresh changes nothing but a look in the repository shows 12401 on the project. If I delete the project from the workspace and check out the project then it shows 12401.
Is this a bug or the expected behaviour?
RAD8,
Subversive SVN Team Provider 1.0.0.I20130122-1700 org.eclipse.team.svn.feature.group
Subversive SVN Connectors 3.0.0.I20120601-1700 org.polarion.eclipse.team.svn.connector.feature.group
There are two different sides of subversion: the server side and the client side.
If you look at the server your assumption is correct. The revision number of any folder is the highest reision number of all content in the folder.
If you now check out your repository the numbers from the server is reflected on your local revision numbers.
If you now change any file then tis file gets a new revision number from the server and this is reflected on the client side. A change to a folder is only counted when there is a structural change to the folder. Else the folder on the client side will sta with the same revision number as before.
So for subversion it is normal that the revision number of a folder may be different on client and server if you worked with the checked out sources.
I'm using subclipse to merge changes from the trunk into a branch and during the "best practices" step, there's a notification that the working copy is not at a single revision. None of the files or folders in the package explorer have the dirty indicator and (having been through this before) even after doing an update, none of the version numbers appear to have changed. What specifically is subclipse looking at to generate this notification? Is there something I can also run from the command line to corroborate this?
It basically means you have a "Mixed Revision Working Copy" which is very normal and common. If you Google it you will find a lot of explanations. A blog post I wrote many years ago is the top hit:
http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
Subversion merge works a lot better if you have your working copy at a single uniform revision. So just run update. The merge wizard will do this for you if you let it.
Outside subclipse, in pure Subversion terms:
You WC may be in Clean state (no local modification), but - in Mixed. Mixed Working Copy will appear, when part of tree updated to revision, different from "Main"
Step to reproduce
svn co http://mayorat.ursinecorner.ru:8088/svn/Hello/
A Hello\trunk
...
Checked out revision 34.
cd trunk
svn up -r 30
Updating '.':
...
Updated to revision 30.
cd ..\..
subwcrev Hello
SubWCRev: 'z:\Hello'
Last committed at revision 28
Mixed revision range 30:34
"Mixed revision range" is warning for you and for your case. I can't recall can this check and how be done with pure svn client: always use subwcrev in build-tasks
For clean Working Copy (svn up in trunk done) subwcrev output
subwcrev Hello
SubWCRev: 'z:\Hello'
Last committed at revision 34
Updated to revision 34
SubWCRev is part of TortoiseSVN
I have a project with 2 branches let's say v1.1 en v1.2 (in the same svn repository).
In v1.1 I modified 2 files and comitted them seperatly (2 revisions).
Now I wanted to merge revision 1 into v1.2 and block revision 2 (may not merged).
(I use eclipse 64-bit with subclipse a Collabnet for merging.)
For the first I choose 'merge a range of revisions', pick revision 1 and merge this into v1.2 and commit.
For the second I choose ... (block one or more revisions); I select revision 2. First symptom of the problem is noticeable here: the already merged revision is still in the list. Anyway, I follow the 'ignore what I don't understand' procedure and continue. A few steps later eclipse asks me if I want to commit the updated mergeinfo property? I choose Yes. Next I get the message 'No files were changed or added since last commit'.
When I restart a merge and choose 'select range of revisions' then I still see both in the list: the already merge revision A and the blocked revision B. When I look at the properties of the project I don't see a single property called svn:mergeinfo. I'm new to this but I thought that was the way svn stores this information?
thanks,
Stijn
I think you need to upgrade your repo to 1.6.x before this will work.