SCM command line operations for conflict merging
We are testing out the SCM command line and are confused about conflict handling. Let's say we have the following scenario:
Dev 1 modifies file A and adds a line of code to the end. Dev 1 checks in the file to his repository workspace. Dev 2 modifies file A and adds a line of code to the end (this would then conflict with the change above). Dev 2 check in the file to his repository workspace and delivers the change to the stream. Dev 1 performs an "scm accept" from his local workspace. We get an error about merge conflicts. Question 1: Now how do we actually manually resolve this? The only thing we can figure is to run "scm conflicts" with a -m and then with a -p to get both versions somewhere on the computer, and then use a GUI merge tool to merge them, and then what should we do? Do we check in the "merged" file and then run "scm resolve" on it? Question 2: Also, is there an easier way to get both the "mine" and "proposed" versions of the file together? For example, in CVS and Subversion, when there is a merge conflict, the two chunks of conflicting stuff get shoved together in the same file with big "markers" around them so you can then edit the file and grab what you need from each conflicting section. Thanks in advance, Mike Johnson |
7 answers
Question 1: Now how do we actually manually resolve this? The only thing we can figure is to run "scm conflicts" with a -m and then with a -p to get both versions somewhere on the computer, and then use a GUI merge tool to merge them, and then what should we do? Do we check in the "merged" file and then run "scm resolve" on it? Yes. Question 2: Also, is there an easier way to get both the "mine" and "proposed" versions of the file together? For example, in CVS and Subversion, when there is a merge conflict, the two chunks of conflicting stuff get shoved together in the same file with big "markers" around them so you can then edit the file and grab what you need from each conflicting section. Not at the moment. That feature was removed in 2.0. It will return in 2.0.0.1. e |
|
Thanks for the reply! Good to hear about that feature coming back. It seems very unwieldy to have to do it by grabbing both files by running "scm conflicts" twice :)
Also, on a side note about the SCM command line -- we seem to notice that operations seem to take longer than the corresponding operations in the GUI. Checkins, delivers, and loads seem slower. (mind you, I have no empirical data for this, just what we've noticed!) Is there some way that we can "optimize" the command line experience to get the same kinds of speeds as the GUI? Thanks, Mike |
Thanks for the reply! Good to hear about that feature coming back. It seems very unwieldy to have to do it by grabbing both files by running "scm conflicts" twice :) Hi Mike You are probably right about the Eclipse UI being faster for certain operations. The GUI seems to be pretty smart about running background tasks so control can return to the user before an operation completes. Not seem any guidance on how to speed up the commandline yet, so interested in any comments you get. anthony |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 30 '09, 3:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Actually, it's not just backgrounding that makes things faster in the
GUI ... the GUI client also caches a bunch of information from request to request that makes things faster. And of course, if you are invoking a new instance of the command tool to execute each command, you pay the startup cost of the command tool itself each time. Cheers, Geoff kesterto wrote: micjohnson997wrote: |
Actually, it's not just backgrounding that makes things faster in the Geoff, OK, so of course the next question is... How do you *not* invoke a new instance of the command tool for each command? Thanks, Mike |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 30 '09, 5:16 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Well, now that's a bit embarassing ... I always assumed that scm.exe
would read multiple commands from stdin ... apparently not! Submitted work item 88934. Cheers, Geoff micjohnson997 wrote: gmclemmwrote: |
Also, on a side note about the SCM command line -- we seem to notice that operations seem to take longer than the corresponding operations in the GUI. Checkins, delivers, and loads seem slower. (mind you, I have no empirical data for this, just what we've noticed!) Is there some way that we can "optimize" the command line experience to get the same kinds of speeds as the GUI? A bulk of the the runtime comes from class loading and other java-related issues. You can try using other VMs (that run slower over the long run, but start up in roughly 2/3 the time that J9 takes) and playing with their optimizations. There should hopefully be speed improvements in 2.0.0.1 and the following 2.x release. e |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.