I'm a new Plastic SCM user, coming to it with Git and Perforce experience.
I had two copies of a local set of files, and copied one on top of the other to make sure that I had all of the files. Plastic SCM seems to have automatically checked out all of the files within these folders. However 90% of them are identical.
How can I revert or cancel my checkout on all the identical files, so I can only submit those with changes? In Perforce I would do this with "Revert if unchanged" or "Reconcile offline work".
There are thousands of files and I don't want to do diff and revert each one manually. Also I don't want to make a commit with thousands of files where only a few are changed.
You can simply uncheck this option and Plastic will avoid counting it as changed files.
Plastic SCM preferences
I found the answer to this right after posting it!
In the Pending Changes tab, select all the files you want to revert.
At the top, click the drop-down next to "Undo changes" and select "Undo unchanged".
That's it!
Related
I am using Eclipse Mars.1 (4.5.1) with EGit 4.1.0.
After a merge from a branch into master, I cannot figure out how to tell EGit to resolve a conflict by simply keeping the version that was in master before the merge, ignoring anything that came into that file as a result of the merge.
This is what I do. My Java projects all point to master. No uncommitted changes in any project.
In Package Explorer view I right-click a project, click Team, Merge.
In the "Merge 'master'" dialog that pops up I select a branch (under "Local"), I leave the "Merge options" on "Commit" and the "Fast forward options" on "If a fast-forward, only update the branch pointer".
I click "Merge". The "Merge Result" dialog pops up and says "Result Conflicting". Fair enough, I was expecting conflicts and I'm going to resolve them manually one by one.
Now, my problem is that for some of the files in conflict the way I want to resolve the conflict is simply to reject any change to that file resulting from the merge; just keep that file as it was before I did the merge.
This should be trivial to do (at least in SVN it was), but I cannot see anywhere in Eclipse how to do that. The merge has filled the file with the "<<<<<<" conflict markers and I just don't see what needs to be done to revert those changes only in that file so that that file simply becomes unchanged with respect to master, which is where all the projects are pointed.
If I right-click on the file in the Synchronize view and select "Overwrite", I am asked if I "want to overwrite local changes". That's exactly what I want, I want the file to have no local changes, so I click Yes. But the result is that the file gets deleted locally, although it exists both in master and in the branch. It disappears from Package Explorer, and since I also had it open in the editor, that editor tab closes away. That's not what I meant by "overwrite local changes" and I don't understand why it happens.
If instead of "Overwrite" I select "Mark as merged" (although the conflict markers are still there), the file is no longer shown as in conflict, but it still has all the conflict markers in it and of course is still shown as changed, while I want it to be unchanged with respect to master.
And if instead I resolve all the conflicts in the other files and I want to commit all the files except the problematic one - so that that one will stay unchanged - when the commit dialog shows up and lists all the files to be committed, each with a checkbox, and I click on the checkbox of the problematic file to exclude it from the commit, the checkbox doesn't get unchecked, and this goes for any of the other files; the checkboxes don't look disabled, but they don't respond to the click.
What am I missing ?
As of now checkout ours/theirs is available on conflicting files in the EGit staging view only
This problem got solved for me in the following way. I don't think it's the proper way (and I'm still interested in hearing about that if anyone knows) because it involves switching between two different Eclipse views, but at least this did the trick for me, and the only reason why this involves the "Synchronize" view is that nowhere else can I find the "Mark as merged" menu entry when I right-click on a file in conflict (neither in the "Git Staging" view nor in Package Explorer).
Open the "Git Staging" view. The files in conflict are shown under "Unstaged Changes".
Among them, right-click the one for which you just want to revert any change resulting from the merge in order to just keep the file unchanged. Then select "Replace With / Ours".
Go to the "Synchronize" view, right-click the file, Mark as Merged.
Now in Package Explorer the file should be shown as not in conflict, just unchanged, so it won't be included in a commit.
In P4V I can select a file, view its history, and use the options under the "show branch history" button to see changes made in other branches.
When I select a directory however, the "show branch history" button disappears. How do I view the history over different branches of all the files contained under a directory?
Probably easiest to use Revision Graph to do this. It'll let you follow the path of all of a folder's files back into other branches (can also do it recursively if there are subfolders).
Be warned: the output can get intense if there's a lot of other branches, and/or a lot of files. There's a filter on it so you can narrow down which files you care to look at though.
I'm trying to rationalize two perspectives which seem to be related (or at least provide very similar functionality): The 'Git Repository' perspective (which I got after adding EGit), and the 'Team Synchronizing' perspective (which I think was part of the EE distribution).
As far as I can tell, I was able to get the Git Repository working (with GitHub), or at least most of the features: The 'Git Staging' Window is working fine, I'm able to commit by dragging files from 'Unstaged changes' to 'Staged changes' and then clicking the Commit icon. Then I'm able to push my changes from the 'Git Repositories' window, by right clicking on the workspace->Remotes->origin->url, and select Push from menu (is that the 'correct' procedure?).
With the 'Team Synchronizing' perspective, I'm no luck to even set it up. Once selecting the 'Synchronize...' frmo the menu, the Git, then I see a table (what is it?). I'm trying various values for the Destination (otherwise, unable to hit the Finish button), but no matter what I do, it tells me 'no changes' for all my projects.
There are also many context-menu item when right clicking on a project, and selecting 'Team'. What are these?
In CVS the Team Synchronize is about the only sane way of managing your incoming and outgoing changes. You can update / merge incoming changes and commit outgoing changes from this one view. Since every commit is discrete and it is non-atomic, the view is fine for this workflow.
In EGit however you already have explicit actions for adding, committing, pushing, pulling and merging. So the team synchronize is largely outside the normal workflow. It behaves much like a glorified synching from a patch - you pick which branch(s) you wish to compare your working directory and it shows you the differences. You can then apply those changes en masse or individually but it's not going to pick up the context, i.e. it's not going to create merge points or whatnot.
So you should train yourself not to use except for exceptional reasons. For example, maybe you have two branches A & B. Somebody committed a change to B and you need only a small part of it, so you could use Team Sync to show the diffs and only apply the ones you need. Or maybe you just want to squash up all the changes on branch B and call them a single commit in A. Then you might use Team Sync rather than screwing around with a rebase when you're going to toss B anyway or its a remote branch.
From my understanding, the "Git repository" perspective is intended for committing files from the working directory to the local Git repository, while the "Team synchronizing" perspective is for syncing your local repository with a remote one.
I found this confusing at first as well, because when using SVN, the "Team sync" perspective was for committing/updating files. Until I noticed that in EGit's Team sync perspective, instead of showing the commit/update buttons, it has the pull/push buttons, which are for syncing two Git repositories.
For the various options that appear under the "Team" context menu, they correspond to a bunch of Git operations. I'd suggest some reading about Git's principle of operation before using EGit. http://git-scm.com/doc would be a good start.
I just created an ignore-on-commit changelist as described in SVN: Is there a way to mark a file as "do not commit"? and it's awesome on the command line, making it much easier to view the changes I care about in the command line.
Having all this power and organization now I select all my projects in eclipse and go to Team > Commit and there is no notion of changelists in the commit dialog and I still have to go through all the changes and tediously select which files to commit.
Am I missing something in Eclipse' Subversive that would allow me to use changelists in the commit dialog?
I found the following setting, but it doesn't seem to change anything...
I see two possibilities here:
1. Using svn:ignore
The easiest solution would be to add the files you don't want to commit to your svn:ignore list.
You can do it in Subversive through the Team>Add to svn:ignore... menu:
2. Using change sets
The alternative is to :
go in the Synchronize view
click the Show Change Sets button
you can then add changed files to change sets (and create new change sets) from the right-click menu.
You can find more information in the Subversive documentation.
I'm pretty used to how to do CVS merges in Eclipse, and I'm otherwise happy with the way that both Subclipse and Subversive work with the SVN repository, but I'm not quite sure how to do merges properly.
When I do a merge, it seems to want to stick the merged files in a seperate directory in my project rather than overwriting the old files that are to be replaced in the merge, as I am used to in CVS.
The question is not particular to either Subclipse or Subversive.
Thanks for the help!
Merging an entire branch into trunk
Inspect the Branch project history to determine the version from which the branch was taken
by default Eclipse Team "History" only shows the past 25 revisions so you will have to click the button in that view labeled "Show All"
when you say "Show All" it will take you back past the branch date and show you all the history for trunk as well so you'll have to search for your comment where you branched
NOTE: if you use Tortise SVN for this same task (navigate to the branch and select "Show Log") it will show you only the branch history so you can tell exactly where the branch began
So now I know that 82517 was the first version ID of the branch history. So all versions of the branch past 82517 have changes that I want to merge into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "All"
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Re-Merging more branch changes into trunk
Insepct the trunk project history to determine the last time you merged into trunk (you should have commented this)
for the sake of argument let's say this version was 82517
So now I know that any version greater than 82517 in the branch needs to be merged into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "Revisions" radio button and click "Browse"
this will open up a list of the latest 25 branch revisions
select all the revisions with a number greater than 82517
press OK (you should see the revision list in the input field beside the radio button)
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Resolving Conflicts
You should be at the "Team Synchronizing" perspective. This will look like any regular synchronization for commit purposes where you see files that are new and files that have conflicts.
For every file where you see a conflict choose "right click - Edit Conflicts" (do not double click the file, it will bring up the commit diff version tool, this is VERY different)
if you see stuff like "<<<<<<< .working" or ">>>>>>> .merge-right.r84513" then you are in the wrong editing mode
once you have resolved all the conflicts in that file, tell the file to "mark as merged"
once all the files are free of conflicts you can then synchronize your Eclipse project and commit the files to SVN
I typically check out both branches and then use the compare to each other option which does a synchronize-like compare of the two source trees. After integrating the changes into one branch, you can recommit back to the repository.
Use Eclipse integration, it works perfectly fine.
The main change from CVS, is that you only merge deltas from a branch, ie changes from one revision to another.
That is to say you have to track the correct start revision somehow (unless you have svn 1.5 merge history)
If you got that right, it's only up to you to get the changes right with the compare editor.
Firstly, if you are seeing ">>>>>" and such in your files when you view them in Eclipse, this probably means that you are not looking at the file with the proper compare editor. Try right-clicking on the file in the Project view or Synchronize view and selecting "Edit Conflicts" to bring up a compare editor that will show you the conflicting regions graphically rather than as text. Note that the compare editor that comes up for "Edit Conflicts" is different from the one that you get when you just doubleclick on a file in the Synchronize view -- the doublieclick compare editor shows the differences between your current file and the way it existed when you last checked it out or updated it, while the Edit Conflicts compare dialog shows the differences between two sources of changes (for instance, the changes you merged versus the changes that existed in your workspace before you merged).
Secondly, you may wish to be aware of a bug in some versions of the Eclipse subversive plugin which causes all files that accepted merge changes to be incorrectly marked as having conflicts. This bug has been fixed, but a lot of people don't seem to have updated to get the fix yet. Further details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312585
Remember that with svn reverting a modified tree to a clean state is fairly easy. Simply have a clean workspace on the merge destination branch and run the merge command to import the modifications from the merge source branch, then synchronize your workspace and you will get your usual eclipse comparison window showing all the merge modified files and the conflicts.
If for some reason you can't solve the conflicts you can svn revert on the project and go back to a clean state, otherwise you do the merge in place and once you are done you can commit. Note that you don't have to commit, once you are done handling the conflicts you can also return to the dev view, verify that the code compiles, run your unit tests, whatever and then synchronize again and commit (once the conflict are locally resolved they won't come back)
last time I looked, when you use subclipse merge command it will overwrite the merged file (using conflict markers to show conflicting areas) and put the original left and right side of the merge in the same place. it shouldn't put anything in different directories.
As a rule of thumb, it is best to commit all merge modifications in a single commit and to only have the merge modifications in the commit so that you can rollback the merge later if needed.
openCollabNet's merge tool for subclipse is pretty neat. There are many merging types available and the merging I just performed with it when seamlessly. I recommend it.
The one thing that syncrhonize view in eclipse lacks is check-in capability. In Team synchronization view I can view all my changes and resolve conflicts, so it would be rather intuitive to check-in right there instead of going back to java view and do check-in.
I would advise not trying to use Eclipse's plugins as your primary access to Subversion.
If you are developing on Windows, TortoiseSVN is the best program that I have seen for Subversion access. Explore to the directory of which you wish to merge, right click on it and use the Tortoise SVN merge option. Assuming a non-interactive merge, once you get conflicts, you'll have to go through each conflicted file and edit the conflicts before marking them as resolved. For this process I recommend a program called KDiff3, which shows your local repository copy (what was stored in the .svn before the merge), your local copy (including any changes), and the copy coming from the repository, and allows you to easily see (and even hand-modify if needed) the result of the merging. It also handles a bunch of minor conflicts automatically.
KDiff3 is portable, TortoiseSVN is a windows shell extension, so if you're using another environment, I would try to just use SVN to merge. But that would be much more of a pain :)
I landed here because I was looking for a way to merge in an external merge editor (KDIFF3) but start the merge from eclipse. I wasn't satisfied with the answers provided above. So here is ho to configure kdiff3 as merge and diff editor for SVN in eclipse:
go to Windows -> Preferences → Team -> SVN -> Diff Viewer
Add a new config (add button):
Extension or mimetype: * - if you wish you can specify different mimetypes for different editors, I didn't need that thus the alquantor.
Diff:
Program path C:\Program Files\KDiff3\kdiff3.exe (or wherever you have your merge editor - sry for the windows path, feel free to add a linux version in the comments or edit this answer.)
Arguments:
${base} ${mine} ${theirs}
Merge:
Program path C:\Program Files\KDiff3\kdiff3.exe
Arguments:
${base} ${mine} ${theirs} -o ${merged}
This will probably work as well for other merge editors, but with a different argument syntax (figure it out an let us know :) ).
The usage is as usual (team->edit conflicts) for merging and compare->foo for the diff view.
Cheers