FW: FW: mercuria destroys everyone's work
FLORENT Philippe
Philippe.FLORENT at edenred.com
Thu Feb 4 10:12:07 UTC 2016
Now we just found that even with an non automatic merge, complete manual override
We select the b version for a line, and save/commit
I check the code and here it is : the fucking c version of that very line
Now I got to fucking tell the customer why that piece of shit is not taking the correct line
Let me guess I am stupid, and kdiff is perfect, right ??
Jesus f.. Christ
Every day there is a new oddity with versioning, and using Git or svn would be exactly the same
The best versioning system is NO VERSIONING AT ALL !!
-----Original Message-----
From: Brandon McCaig [mailto:bamccaig at gmail.com]
Sent: mercredi 20 janvier 2016 19:51
To: FLORENT Philippe
Cc: mercurial at selenic.com
Subject: Re: FW: mercuria destroys everyone's work
On Wed, Jan 20, 2016 at 07:39:05AM +0000, FLORENT Philippe wrote:
> Well no, as I said we did not change our ways, and still followed
> regular pull -> merge/commit -> push
>
> The only thing I found to resolve this is to use noautomerge in the
> hgrc file (or something) ⦠still have to test it
The noautomerge is going to skip Mercurial attempting to do the merge for you and always force you to use a tool to do it yourself for every file. That is extremely counterproductive because it will force you to do the simple jobs that the machine can do. You should still review the results (as always), but it is adviseable to let the machine do this for you. It's unlikely that this is the result of your problems (if you think it is then you should submit an example of it for analysis).
If I may, it sounds to me like you and your colleague are just having trouble merging. That's understandable. It can be a very complicated thing, depending on what you're trying to merge.
That's not Mercurial's fault. Machines are not good at understanding what people intend. Conflicts occur because what you've both intended isn't likely compatible and the machine cannot guess how to fix it. It falls on your shoulders to figure it out.
There are various merge tools available so you may want to experiment more to see if there are any that you can understand better. The best way to get good at resolving conflicts is to do it a lot. You'll also need to be able to understand what each other have done, and communicate with one another if the solution isn't obvious to even you.
Personally I prefer internal:merge (or internal:merge3 lately, but this can be more confusing at times). I find that the GUIs are too complicated and muddy the waters even more. I am more adept at manipulating the raw text. There is no easy button for merges. The hardest part is understanding what to do. Actually doing it is the easy part.
You can configure your merge tool by setting 'ui.merge' in Mercurial.ini, .hgrc, etc (see 'hg help hgrc'):
[ui]
merge = <value>
Mercurial is not destroying your work. In the worst case scenario the work will remain in history.
If you can figure out how to make machines merge complicated work perfectly you'll be rich.
m %96 AC at 3=6> :D E92E E96 @?=J 7C66 2=E6C?2E:G6 :D vx%]]] ?@ H2J m xV== FD6 E9:D @G6C=J 4@>A=:42E65 A24<286
p>;25 |2D25i %96 $E@:4 @7 ~A6? $@FC46,`. D2:5i
m x?5665[ H6 D9 at F=5 36 >@C6 4@?46C?65 :7 H6 7:?5 E96 7@@= m 28C66:?8 H:E9 FD]
,`. 9EEAi^^2>2D25]>6^a_`e^_`^`b^E96\DE@:4\@7\@A6?\D at FC46^
Regards,
--
Brandon McCaig <bamccaig at gmail.com> <bambams at castopulence.org> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bambams.ca/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: signature.asc
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20160204/621b381c/attachment.sig>
More information about the Mercurial
mailing list