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.
Related
When I do a commit from subversive it populates a list of (and selects by default) any new files in my project directory. I want only those files which I have explicitly added to version control to show up in the commit dialog.
This seems to be the same basic question as this StackOverflow question, but I really want to involve git.
This is a huge pain because people keep accidentally checking in random generated files and directories (e.g. VC++ temp files: **/Release/vc70.pdb, buildLog.html ) and random settings files for eclipse plugins.
I found a "Check the new resources in the commit dialog" option under Preferences > Team > SVN. This just prevents them from being auto selected, but I want them not to show up at all.
I also tried isolating all the different change sets available under 'Models'. Even with No change sets selected commit still adds all uncommitted files on the file system to the commit list.
Eclipse lets you specify resource name patterns so that files which match a pattern are excluded from version control. Find it at Window..Preferences/Team/Ignored Resources. You can specify paths like /temp/something., or just filename patterns like *.tmp.
I'm using Perforce, not svn, but I think it works the same way with any version control plugin.
If a file is committed several times with various changes, how can I fetch one change at a time, i.e., one changeset at a time?
I use eclipse, subversion, and subclipse, and I can't change the former two for the time being (or the MS platform..).
In my Team/Synchronization view in eclipse (using subclipse), choosing the changeset model, a file seems to be listed only in the latest relevant changeset even if all changesets are listed. So an earlier changeset doesn't necessarily show the full set of files in the original commit, nor the original diff for a file in a commit.
Update: I'm thinking about using changesets for simplified code review, so I'd like the partial update represented for all the files commited in one changeset. It's easy to get diffs and specific revisions for specific files in eclipse, but I'd like to step through all the changes in one specific commit/ changeset in a practical manner.
As I'm sure you know, svn up will by default grab the latest revision of the file.
However, you can use the -r parameter to svn up to grab a particular revision of a file. So if you know a file was committed in revisions 5, 7, and 9, you could do this:
svn up -r5 myfile
svn up -r7 myfile
svn up -r9 myfile
I believe (but I don't have an installation of it in front of me) that Subclipse has a similar option, labeled something like "Update to Revision..."
Subversion does not support atomic changesets.
(Note: If anyone can prove me wrong, I'll happily switch accepted answer.)
I've compared Git and Subversion using TortoiseGit and TortoiseSVN (and looked at what is possible on the command line).
With both Svn and Git I can update to a certain revision, or see and update to different versions of only one file at a time.
With both Tortoise clients can I see individual commits (revisions) from the repository and look at changes between a revision and the previous revision. (Note that I can't seem to do this in Eclipse, ref the question.)
Only with Git, however, can I update to or cherry-pick an isolated commit. The closest I've seen to this functionality in Subversion is to update to head and then revert a certain revision with a "subtractive merge"...
Test setup: make a project, check out or clone the project, make 2 separate commits to repository from elsewhere, including at least one file that is modified in both commits.
Then, with Git: fetch remote changes.
Then, with both Git and Subversion: look at the log.
I just spent a fair amount of time selecting the files and directories I wanted under version control. I'm running subclipse under eclipse. I right clicked, Team, Add to Version Control. Now I want ONLY those files committed without right clicking the whole directory which contains a huge number of media files that I don't want handled by version control. If I go Team/Commit under that directory it hangs for a very long time... I thought by "Add to Version Control" there was an option to commit those files only. I just don't know how to do it.
I hope I explained the question properly..
UPDATE:
Since people are talking more about ways to ignore files rather than committing what you're marked as "Add"ed to Version Control, let me put this a different way. What does "Add to version control" do exactly? It seems to be a feature without use.
Subclipse includes both unversioned files and files you specifically marked for addition when you open the commit dialog. It does not perfectly mirror the behavior of the command-line client. You have two options: uncheck each file you do not want to commit in the Subclipse commit dialog or use the command-line svn tool to commit. The command-line tool will only commit files you have marked for addition and will ignore the other files. Here's a simple example:
$ touch file
$ svn status
? file
$ svn add file
A file
$ svn status
A file
$ touch file2
$ svn status
? file2
A file
$ svn commit -m "Added empty file"
Adding file
Transmitting file data .
Committed revision 2.
? denotes a file that it unknown to svn and will not be put under version control automatically by svn commit. A denotes a new file that is scheduled for addition. Subclipse is trying to mirror this behavior by allowing you to "add a file to version control", which is the equivalent of the command-line svn add. but also includes unversioned files not scheduled for addition in its commit dialog (which I personally find somewhat annoying). If you run svn status on the command-line, those files which you "added to version control" in Subclipse will be marked with an A while those you did not will be marked with a ?. You won't have to run any svn add commands since you did that already in Subclipse.
You can add a pattern in Preferences/Team/Ignored resources (it's not the same as svn:ignore). You can also delete it, if it is no longer helpful.
use svn:ignore for the resources you don't need under version control (Team > Add to svn:ignore)
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.
Let's say I have committed some bad changes to Subversion repository. Then I commit good changes, that I want to keep.
What would be easiest way to roll back those bad changes in Eclipse, and keep the good changes? Assuming that files relating to bad changes are not same as those relating to the good changes. How things change if good changes were made to same files as bad changes?
I am mostly looking a way to do this via Eclipse plugins (Subclipse or Subversive) but commandline commands are also interesting.
In Eclipse Ganymede (Subclipse)
Select project/file that contains bad change, and from pop-up menu choose:
Team -> Show History
Revisions related to that project/file will be shown in History tab.
Find revision where "bad changes" were committed and from pop-up menu choose:
Revert Changes from Revision X
This will merge changes in file(s) modified within bad revision, with revision prior to bad revision.
There are two scenarios from here:
If you committed no changes for that file (bad revision is last revision for that file), it will simply remove changes made in bad revision. Those changes are merged to your working copy so you have to commit them.
If you committed some changes for that file (bad revision is not last revision for that file), you will have to manually resolve conflict. Let say that you have file readme.txt with, and bad revision number is 33. Also, you've made another commit for that file in revision 34. After you choose Revert Changes from Revision 33 you will have following in your working copy:
readme.txt.merge-left.r33 - bad revision
readme.txt.merge-right.r32 - before bad revision
readme.txt.working - working copy version (same as in r34 if you don't have any uncommitted changes)
Original readme.txt will be marked conflicted, and will contain merged version (where changes from bad revision are removed) with some markers (<<<<<<< .working etc). If you just want to remove changes from bad revision and keep changes made after that, then all you have to do is remove markers. Otherwise, you can copy contents from one of 3 files mentioned above to original file. Whatever you choose, when you are done, mark conflict resolved by
Team - Mark Resolved
Temporary files will be removed and your file will be marked changed. As in 1, you have to commit changes.
Note that this does not remove revision from revision history in svn repository. You simply made new revision where changes from bad revision are removed.
You have two choices to do this.
The Quick and Dirty is selecting your files (using ctrl) in Project Explorer view, right-click them, choose Replace with... and then you choose the best option for you, from Latest from Repository, or some Branch version. After getting those files you modify them (with a space, or fix something, your call and commit them to create a newer revision.
A more clean way is choosing Merge at team menu and navigate through the wizard that will help you to recovery the old version in the actual revision.
Both commands have their command-line equivalents: svn revert and svn merge.
If you want to do 1 file at a time you can go to the History view for the file assuming you have an Eclipse SVN plugin installed. "Team->Show History"
In the History view, find the last good version of that file, right click and choose "Get Contents". This will replace your current version with that version's contents. Then you can commit the changes when you've fixed it all up.
In Eclipse using Subversive:
Right click your project > Team > Merge
In the merge window, select the revisions you want to revert as normally but also enable checkbox "Reversed merge".
Merge as normally.
I have written a couple of blog posts on this subject. One that is Subclipse centric: http://markphip.blogspot.com/2007/01/how-to-undo-commit-in-subversion.html and one that is command-line centric: http://blogs.collab.net/subversion/2007/07/second-chances/
The svnbook has a section on how Subversion allows you to revert the changes from a particular revision without affecting the changes that occured in subsequent revisions:
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo
I don't use Eclipse much, but in TortoiseSVN you can do this from the from the log dialogue; simply right-click on the revision you want to revert and select "Revert changes from this revision".
In the case that the files for which you want to revert "bad changes" had "good changes" in subsequent revisions, then the process is the same. The changes from the "bad" revision will be reverted leaving the changes from "good" revisions untouched, however you might get conflicts.
I have same problem but CleanUp eclipse option doesn't work for me.
1) install TortoiseSVN
2) Go to windows explorer and right click on your project directory
3 Choice CleanUp option (by checking break lock option)
It's works.
Hope this helps someone.