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.
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.
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.
Specifically:
Why do I need to explicitly enable "Enable baseless merges" all the time? I am integrating from my branch to the trunk.
What does "Enable integrate over
deleted targets" mean? Shouldn't it
do this by default? If the file
doesn't exist, and you integrate to
that branch with the file, it should
create the file, right??
What does "Do not get latest revision
of selected files" have to do with
integrating? I should be choosing a
source revision, and a target (to
create a new target revision).
What does "Disregard indirect
integration history" mean? I've never used it, since it sounds scary.
I would be grateful to know, as I am a little unsure of what options to enable when I am trying to do various integration tasks from our trunk to various branches or vice versa. (I am not the buildmaster, but hey, I want to know what he knows).
Why do I need to explicitly enable
"Enable baseless merges" all the time?
I am integrating from my branch to the
trunk.
Can't help you here. Something is not right.
What does "Enable integrate over
deleted targets" mean?
If the target file has been deleted and the source file has changed, will re-branch the source file on top of the target file. Without this option, a file on the branch, that has been changed on the branch and deleted on the trunk, would not be allowed to be integrated back into the trunk.
Shouldn't it do this by default?
Not if you are integrating a file back into the trunk, which you branched from the trunk, then deleted on the trunk. Normally 'p4 integrate' avoids mixing outstanding edits with a deleted file. You have to use the advanced options to tell it how to deal with a deleted file.
If the file doesn't exist, and you
integrate to that branch with the
file, it should create the file,
right?
When integrating a file, that previously never existed (i.e., it was added to the branch), from one location to another, yes, Perforce will simply create it in the location into which you are integrating. However, if the file originally came from the trunk, was deleted on the trunk, and now you're trying to integrate it back into the trunk from the branch, you have to tell it what to do via these integration options. Here's the command line switches to which these options correspond:
Enable integrations around deleted revisions = -d
Integrate over deleted targets = -Dt
Delete target file when source is deleted = -Ds
Try to integrate changes when source is deleted and re-added = -Di
You can learn more about them in the integrate command help (type "p4 help integrate" at the command line).
What does "Do not get latest revision
of selected files" have to do with
integrating?
This tells Perforce to use the workspace revision of the target file. By default, the head revision of the target file is automatically retrieved into the workspace before integrating. Say you have made one revision to a branch file and integrated it back into the trunk. The trunk and branch now have two revisions of this file. You submit a change to the branch file so it now has 3 revisions. You sync the branch file back to revision 2. If you were to do a normal integration right now, Perforce would assume you want to integrate everything up to the head revision and would integrate revision 3 of the branch file into the trunk. If you were to select this option, it would say, "all revision(s) already integrated" because you have revision 2 in your workspace. It would be the same as attempting to integrate with the "Limit the range of the integration:" option set to "Integrate all revisions up to:" Revision 2.
What does "Disregard indirect
integration history" mean? I've never
used it, since it sounds scary.
I can't figure out, nor find any info about, what this does.
In general, to merge two files, perforce looks for a "base", the closest revision to the two files, and uses that to provide a much better diff than just directly running a diffing the two files. See Knowledge Base Article. Without knowing your perforce setup, I couldn't say what was going wrong, however, p4win has some nice graphical tools to visualize branches, you might be able to determine why perforce can't find a base for you. This is also what "Disregard indirect integration history" does: stops it from looking for the base.
For the "don't sync to head": when integrating, your "target" is the files in your local client, which you aren't specifying a revision for; instead, perforce will either sync your revision head (if you don't use "-h"), or will use the one you currently have. You can't specify an arbitrary revision because your local client only has a particular one.
"Enable integrate over deleted targets" can lead to problems if done blindly. Here's an example: Imagine you refactor your code in your next release branch, and eliminate a source file as a result - the functionality was merged into some other source files. You then fix a bug in that original source file in a maintenance branch for the previous release. If you integrate over delete by default, the dead source file comes back, but it won't be built and the bug wouldn't have been fixed. It'd better to be warned that this occurred so you could manually merge the fix into the other source files.