Having recently moved from Subversive to Subclipse, one thing that became immediately apparent was the lack of an override and commit option.
This can be quite frustrating when a conflict arises and we just want to overwrite the remote version with our local changes.
Mark as merged doesnt really do what it should in my opinion.
If i mark the conflicted files as merged, it actually rolls my local code back to to what it was before i made the changes and the code in the repository is still different.
I then have to perform an update and recode my changes in order to be able to do a successful commit.
Surly this is a receipe for loss of code, imagine a whole bunch of methods or variables just evaporating from your code,
we dont want to have to back up our workspace any more than we already do and as yet i dont have a photographic memory.
We moved to Subclipse as Subversion seemed to be a little ‘flaky’ performance wise, but to be honest without the override and commit feature, Subclipse is pretty useless to us.
i am a bit surprised by this, see also the other thread about svn
Why is in now in all those years that i use subclispe, this never really bothers me, and also i have never heard this complaint from any of my coworkers.
How come that you want to override changes that another person already made and committed to svn that often??
I cant even remember that i wanted to do that once in all my live that i use subclipse/svn… (or cvs)
At some point conflicts will arise, when this occurs shouldn’t we have an easier option to write local changes straight to SVN without losing anything?
My point was not that we do this on a really frequent basis but more that it could cause problems to arise.
If a user is new to Subclipse and is maybe not aware of the full feature specification then potentially he/she could end up losing alot of data, actually even if they are aware of the spec this could still occur.
Its really really dangerous when you just do override and commit!
Thats a very dangerous option! You really really have to know what you are doing then
Conflicts shouldnt just be overridden… Then you are throwing away changes (and maybe also loads in other places!!) when you just dump yours over it.
Best is just to update it all, and then resolve the real conflicts with Team->Edit Conflicts… and Team->Mark resolved…
jcompagner:
Its really really dangerous when you just do override and commit!
Thats a very dangerous option! You really really have to know what you are doing then
Conflicts shouldnt just be overridden… Then you are throwing away changes (and maybe also loads in other places!!) when you just dump yours over it.
Best is just to update it all, and then resolve the real conflicts with Team->Edit Conflicts… and Team->Mark resolved…
Johan - if you update all then local changes are overwritten - are they not??
If so what is then to edit in Edit Conflicts?
Its really not the dangerous option you portray - we would never commit willy nilly - but where there is a true conflict one element has to win - and we’d like the choice of the left or right side?? Is that not reasonable.
Right now it seems that any conflict will always overwrite the local version regardless of correctness???
no update will merge, overwrite and update thats will over write everything you made (or revert)
But update just merges the changes from others with your changes
And if there are no conflicts (conflict is when both changed the same line). Then there is no problem
your changes are there and the the latest changes from the repository are also in the file.
Then you can still test if it works and commit that change
You really shouldn’t say “just override the repo version with your changes”
Because you are afraid that you loose your changes but with that override and commit you are throwing away ALL the changes other persons did in the time that you did your updates!!
If there are conflicts, so you and a coworker changes the same line, then you can still do an update
That will merge everything that can be merged. And then you have to resolve the conflicts through Team->Edit conflicts… and then when you have resolved the conflicts (red stuff)
you can then say Team->Mark resolved… that you have fixed the problems in the file (you did the merge manually for the conflict lines) or you can say
that you just want your version, or the incoming version. But be aware that in those last 2 options you are throwing away stuff! (your stuff or the other team member stuff)