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.
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.
I am using subclipse plugin in Eclipse to use SVN repo. for commit the source changes i use [Right click -> Team -> Commit]
I need to pull the latest changes from SVN repo. i am seeing options for updating the source
Right click -> Team -> Update to Head &
Right click -> Team -> Update to Version
Which one i have to use to update the latest changes in my local repo and what is the difference between them. Please suggest.
The difference is following:
Update to HEAD will do svn update.
In other words it will update your working copy to the last revision from the repository.
Synchronize with Repository is something similar to svn status -u, but even more.
It will open a Synchronize tab (or perspective) that displays overview of your local (outgoing) modifications versus repository (incoming) modifications.
In this tab or perspective, you can review and synchronize (commit / update) individual files, see differences between your working copy files and incoming files from repository, browse commits history, resolve conflicts.
Update to Revision:
The standard Update command has no options and just updates your working copy to the HEAD revision of the repository, which is the most common use case. If you want more control over the update process, you should use TortoiseSVN → Update to Revision... instead. This allows you to update your working copy to a specific revision, not only to the most recent one. Suppose your working copy is at revision 100, but you want it to reflect the state which it had in revision 50 - then simply update to revision 50
Update to Revision can occasionally be useful to see what your project looked like at some earlier point in its history. But in general, updating individual files to an earlier revision is not a good idea as it leaves your working copy in an inconsistent state. If the file you are updating has changed name, you may even find that the file just disappears from your working copy because no file of that name existed in the earlier revision. You should also note that the item will show a normal green overlay, so it is indistinguishable from files which are up-to-date.
In general, I highly recommend you to check out the SVN Handbook. At least first two chapters.
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.
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.