I use SVN as check-in tool and have installed Subclipse plugin in my eclipse.
I have done some changes in trunk. I have to merge my changes(from trunk) to some branch.
I have never done merging of code. I have searched it on google and found little confusing.Can someone please let me know the steps to follow.
Did you install the merge plugin from the Subclipse web site?
The general process is that you want your working copy to contain the branch you want to merge into. So if you want to merge from trunk to a branch, you should have your branch checked out.
You should do Team > Update so that your working copy is at the latest HEAD revision for your branch. This will make merge faster and run better.
Then do Team > Merge. The wizard presents some options depending on whether you want to merge all changes from trunk that are not already in the branch or whether you want to select a specific revision(s). Normally you want to do the former when possible.
You have to enter the path you want to merge from, so something like /trunk or /ProjectA/trunk or possibly something like /trunk/some.company.projecta etc.
Just make sure the "relative path" matches what you have checked out.
Then just click OK.
Merge is like an intelligent editor for your working copy. When it is done you have changes in your working copy and those still have to be committed. Be sure to commit the entire working copy so that the SVN merge tracking information is all committed with the changes.
Related
My team and I often exchange patches created in eclipse when working on the same parts of code. I just made a patch for my teammate that includes our changes he had just given me and a function I just added. When I save the patch in a txt file and open it, I see that function.
(I created the patch by right clicking on my project folder, Team -> Create Patch)
He is taking the patch and he has all the same changes in his code except for that one function. He right clicks on the project folder and Team->Apply Patch. He sees a lot of conflicts in the Apply Patch wizard because the wizard is seeing all the same code already in the patch in his workspace (minus that one function I added). He applies and gets no errors. HOWEVER, the one function doesn't go into his code.
Why is this? I thought maybe he had to revert all of his code first and then apply the patch, but it should work regardless, right?
So to be clear here was the process we just did:
I just pulled some changes from a remote repository holding my teams project.
This is the message I received on pull:
Apparently, one of my partners made changed to the same file as me.
How do I proceed from here? The message is very vague. Was there an error? Do I have to undo what I did? Does he have to?
I faced this issue today and below solution works for me.
Do a git stash. This will consolidate all your local and conflicting changes.
Do a git pull now
Do you have uncommitted changes in the file that's in your working copy? Or is your working copy clean? The EGit documentation guides you thru the latter scenario.
In my experience, the error dialog posted by #lmray is what EGit shows when a local working copy has uncommitted changes. EGit wishes to merge in information from the remote but I'm told it will not modify a dirty working copy. To proceed, you must first commit your changes locally, giving you a fallback point, then request merge again. The merge should then produce a merged file, hopefully without any conflicts.
Thanks to #B. Dalton for trying to straighten me out - my dirty working copy file had uncommitted changes, and a local git wizard explained things.
Digression: this is a mental adjustment if you (like me) were used to working with SVN, which would happily pull remote changes into a dirty local working file. Not saying that was better, just that git works differently. I'm still struggling to convert my SVN-trained intuition over to suitable expectations for Git.
You must manually resolve the conflict by incorporating your partner's change into your code and committing the manually merged file.
Alternatively, if your changes aren't too complex, you may revert (throw away) your changes to that file, update your code to pick up your partner's changes, and then redo your work.
See http://wiki.eclipse.org/EGit/User_Guide#Manual_conflict_resolution
In Eclipse :-
Right click -> click on 'add to index'
Add conflict file in staged area
Right Click ->click on commit
Add conflict file in local repository
Pull
You will get all changes (change in remote repository and local repository)
Changes mentioned as Head(<<<<<< HEAD) is your change, Changes mentioned in branch(>>>>>>> branch) is other person change, you can update file accordingly.
Right click ->click on add to index
Right click -> commit and push
If I have done some local changes to Abc.java and then I go for 'Update to Head' for the same file, it does not undo the changes. Why?
I suppose you're using SVN. If so, then that's what it's supposed to do. update will try to merge the changes from the repo to your working copy, so that you may then test your changes with the latest version from the repo, and commit them once you have verified everything is OK.
If you want to undo local changes, you need to do a revert.
Read the SVN book, it's very well written and explains everything clearly: http://svnbook.red-bean.com/
I have a CVS repository in which I have a set of Eclipse Java projects where I need to roll HEAD back to the state it was at a specific time yesterday essentially abandoning all commits happened since said time.
I've tried different things, including using "Replace with another branch or version" which gives the proper sources, but where it appears that CVS now thinks I'm actually working "back in time" instead of in HEAD but with other sources which result in changed files showing up in Team Synchronize etc. Also commits tells me I'm working on a sticky tag and fails.
So, what is the proper way to tell Eclipse 3.5.1 that I need to rollback HEAD to yesterday?
I usually use the following for individual files:
Replace With -> History
Which can be found under the right click menu
Pick the version you want (it also includes eclipse locally saved versions)
Then commit to make it the HEAD
I ended up manually merging the files up in HEAD and very, very carefully checking in the sources. This was no fun.
Unless you have a tag in CVS, you will have to examine each file for this, and choose the version to revert to. (it is due to the way CVS stores changes, they are not file system snapshots like other SCMs).
You did a checkin in CVS with many files and after that you want to undo that?
My solution:
Mark the files (if no good checkin after the bad checkin you can mark all) --> Right click "Compare with" --> With Branch or Version --> Dates --> Add Date --> Take Date where you know the HEAD is ok --> Now you are in the Synchronize view, mark all files --> Replace --> Check in the files again
This will not really undo your CVS checkin (history) but you get with not too many clicks the old state. And you dont have to do it file for file.
I have a Java project in a SVN repository, with a bunch of .java files, each of those files has a licence agreement flower box at the top of the file (I have customers which have licenced the source as well as running the product).
Is there a good way to be able to modify / maintain the licence text in one place rather than having to update all the source files manually if it changes?
Looking at some similar (but not identical) questions it seems like SVN does not have this functionality out of the box - what other approaches would be most suitable?
Edit: Ideally the solution would act like the SVN keywords (Id, Author etc.) rather than being a build-time solution. The customer has access to the SVN repository too, so it would be ideal if the licence text was present in the SVN version of the file. I know SVN has commit triggers - what's a simple way to implement that?
Edit 2: Looking at the SVN hooks it doesn't look like what I'd like to do is possible. I guess build process that can be run when the text changes is ok - since it won't change too often.
Modify the source files that need to contain the text of the license to contain some token instead, and then move the license text to a single file that's kept in subversion. Finally, as part of your build process, add a step that substitutes the text of the license for the token. At my job, I do something along these lines using a combination of sed and make. You could then execute this single step before distributing the source to your customers.
ANT can do the substitution easily. Look into the <copy> target.