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
Related
Using Win7 and TortoiseSVN, I created a plugin, followed the directions for first committing trunk, then created a branch/tag at /tags/x.y.z.
Except I forgot to update the version number at /my-plugin/trunk/my-plugin.php before I committed trunk and tagged the new revision.
The revision shows up in the plugin tags and as an alternative version -- but not the current stable version on wordpress.org/plugins/my-plugin/. Wordpress.org doesn't recognize it as the current stable version, even though I wrote it as such in readme.txt, perhaps because it still has the old version number at /my-plugin/trunk/my-plugin.php and /my-plugin/tags/x.y.z/my-plugin.php.
I want to either
a. delete the bad revision at /my-plugin/tags/x.y.z so I can recreate it correctly, or
b. edit/update the bad revision at /my-plugin/tags/x.y.z.
I tried switching to /my-plugin/tags/x.y.z so I could merge trunk to x.y.z, but I got this message:
Switch E:\subversion\wordpress plugins public\my-plugin to http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z, Revision HEAD
'http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z' shares no common ancestry with 'E:\subversion\wordpress plugins public\my-plugin'
What did I do wrong, and how can I fix it?
Easy way:
checkout tag
fix version number
commit
I used SVN/CVS for a long time just as a place where my code stored is. But now I came to a point where I need a "best way to do".
We have several branches.
For Example:
Release1 (shipped),
Release2 (not finished, contains new features),
Fix1 (contains bug fixes for Release1 and will be shipped after customer tests),
Fix2/trunk (The trunk is our current development state with Fix2).
And now we come to my problem.
I cannot say if Release 2 is shipped before Fix1 or Fix2 and I have now a Hotfix for Release1. Just a few files, but it was urgent.
What is now the best way to get the changes in all branches?
Auto merge will also merge differences that are branch specific. Is the best way to merge it by hand?
There has to be a way like: I mark my change with ID "abc" and say merge only changes of abc in all branches.
Btw. I am using Eclipse with Subversive. Maybe a tool outside eclipse will be better!?
I use Subclipse plugin for Eclipse. You can probably do this with svn command line also. If your fix is isolated to a single revision number then you can merge just that revision to the trunk(or any other branch).
branch1 (revision 103) -hotfix
trunk (revision 100)
Using Subclipse, you can right click the file then choose "Team"->"Merge." Select either "Merge a range of revision" or "Merge two different trees" option then provide the source url and revision to merge to the target tree.
From command line... given that your current working directory is the trunk:
svn merge -r 103:103 http://svn/branches/branch1
You probably can't merge to multiple branches and that's probably better because you want to be careful with the merge process.
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 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.
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.