I am using Mercurial and it's configured to open Beyond Compare when there is a conflict when merging. BC opens just fine and shows me the two files, but I have no idea what to do after that.
Normally in BC there are arrows next to the lines which differ where you can click on them to move the selection to the left or the right. No matter how I select a section I can not move code from one side to the other, or select a specific section as the one I want to keep. This UI is very consing. I basiclly can see the differences but don't know how to tell BC which one I want to keep.
To perform a 3-way merge with Beyond Compare, you must have the "Pro" version. The "Standard" version does not support the feature.
Do you know which one you have?
Related
Stryker-net has an option since.ignore-changes-in and I'm trying to understand in which use case it may be useful to ignore non C# files 1.
The doc gives that example of value ['/*Assets.json','/favicon.ico'], but if my last commit changes only Assets.json and if I run stryker with "since": {"target": "<sha1 of my previous commit>"}, then no mutation will be found on this change, with or without this ignore-changes-in option, right?
What am I missing?
1: Sure, if I don't find it useful I could just avoid using it on my personal projects. However I'm responsible for providing stryker in CI for several teams in my company and I'm hence interested in making sure I have a good understanding of the consequences of using (or not) this.
I can think of two cases.
First, it might bring some performance gain (just by reducing the amount of files Stryker will get to), e.g. when your change updates 100 XML localizations of some string.
Second, you might have real code you don't want to run Stryker against. E.g. you have some Obsolete folder with a bunch of projects you don't care about but which automatically updates with some renaming and so on. This might be interchangeable with the mutate option, unless you want to have different filters for "normal" and "diff" Stryker executions.
I created various flowcharts of processes with the latest visio of a small, complex company (not done yet, but there will be approximately 8 visio files, each with 3-6 sheets).
I am currently looking for a way to present the final result, my idea is to save those files as a website (VML). The problem however is, that I want one single file: therefore my question, how can I merge those files?
I tried to use my very limited html knowledge, the site didn't open anymore. I tried to use "Microsoft Expression Web 4" and just copied 2 test files in there, but it was not usable. My goal is to have on the left side contents, which are linked to the actual visio drawings (think: visio file1 - sheets1.1-1.5; visio file2 - sheets2.1-2.3,...)
Thanks a lot for any help (or other ideas), I am going crazy over this!
How much easier would it be to merge the drawings in Visio itself, before exporting to HTML. Just open the files side-by-side and drag the pages from one document to the other. You may need to press the control key to avoid moving the shapes instead of copying them.
Say you have two “main-line” branches that have been developed separately for a long time, when you come to do the merge between them, you wish to split the work other all your developers.
E.g. you wish your C# programmer to merge the C# cope, while your TSQL programmer is merging the stored procs.
I wash all developers to be able to see what still needs to be merged and the results off each other merges, can Mercurial help with this?
[I am assuming there is more than one developer left after they have been told that they will have to do the merge!]
As I have been asked in the comments, this is how I think we got into this state…
If I understand the history correctly from before I joined. One large customer came along and said “we will pay you a lot of money if you add x,y, and z to your product, but we are not willing to take the risk of you giving us any changes that we don’t directly benefit from (they even put some of their own programmers on the team to check they were not getting other changes).
In the few years that the work was going on for this large customer, other customers said they would not buy the product if we did not add, a, b, and c”.
The large customer was not willing to pay for x,y,and z to be done in a way (or to be able to be turned off) that did not break the product for other customers that used it in different ways, and most of the programmers that understood the system where being sold to the large customer, so there was no man power (until now) to fix x,y,and z so they could be given to all our customers.
(Basically trying to build a product based on consulting income - the fact that we were brought by a company that is closely related to the large customer in the meantime just make the politics more complex.)
At the time all this started the product did not have much automated test coverage, the code base goes back to when .net v1 shipped and all the features are well integrated both in the UI and in the source code.
Hopefully history will not repeat itself, but it is very hard for programmers to say NO in a City that does not have many software companies. We are now moving to Mercurial, and I wish to know how we could cope with Mercurial if history did repeat itself! (I am also starting to question if Mercurial is all it is made out to be compared to Perforce)
Yes, there is a workflow for that scenario.
Plan ahead, know before you branch which branch will merge into which later on, and make sure you merge into it regularly.
Example: You have the default branch, and create a feature branch that at some point should merge back into default. Periodically, merge from default into your feature branch to ensure it is up to date with all changes in default. This creates smaller conflicts along the way. At the end, you do one last merge into your feature branch, fix any conflicts, and then merge it into default.
This avoids "The Big Merge" at the end and creates conflicts that are easier to manage.
One sensible approach could be to use hg convert to split the repository into smaller parts (C# part, TSQL part etc), perform merges on those smaller and more fine-grained repositories, and (if keeping original repo is of importance) just commit the results back onto original repository once they are ready.
Probably the closest to what you want to achieve is to merge one change-set at a time. This avoids the big bang merge by doing lot's of little merges. If you have a clear separation between your C# devs and TSQL devs (which is sounds like you do), then you should be able to allocate each change-set to the right group.
The big negative with this approach is that you won't be able to speed up the process by doing change-sets in parallel.
The big positive with this approach is that you can test after each merge (or a small set of merges), making it easier to track down the changes that break your application. If you don't currently have a strong automated test suite, I would strongly recommend beefing it up first.
i want to add a text column to the MMBE table, it could be the lot size text field: KZTXT or any other (that is the one they are using right now, but do not want to click on it to see it, instead just see it in the front page). it will just add comments when the material has quanitites in quality inspection
thx
There are two possible answers to your question:
if you want to add a column to a table, you can go to the appropriate transaction (I think se11) and add the column
the way you've worded your question it sounds like you want to display a new field in a transaction's screen. The answer to this question depends on the capabilities of the relevant SAP module, some offer pretty generic ways to define your own screens (e.g. business partner), some offer add-on capabilities (usually in a sub-menu or specific sub-screen), with most (especially if you're talking about the "front page"), you may be foreced to resort to a modification of a standard SAP screen. This can be done using the regular development tools (se80, ScreenDesigner etc.), but there is a whole other level of thinking required if you really want to go down that road.
MMBE is a transaction, not a table. It refers to SAP standard report RMMMBESTN.
There are several steps to take in order to add a field to the report:
Does the field that you want currently exist in a SAP table? If yes: go to step 3
If no: You have to add the field to APPEND structure of the appropriate SAP table in SE11. In this case you have to also consider how this data is going to get into the table in the first place, who's going to maintain it etc. (I'm not going into that)
If yes: You have to enhance report RMMMBESTN. In a ECC6 System you can use any of the enhancement Spots supplied. In earlier systems you may have to repair the program.
DO NOT copy transaction MMBE to ZMMBE and then change the program. When you upgrade the SAP standard program may change. If you repair a program or use enhancement spots SAP Modification assistant will help you to apply your changes to the new program - otherwise you're on your own.
On a wiki-style website, what can I do to prevent or mitigate write-write conflicts while still allowing the site to run quickly and keeping the site easy to use?
The problem I foresee is this:
User A begins editing a file
User B begins editing the file
User A finishes editing the file
User B finishes editing the file, accidentally overwriting all of User A's edits
Here were some approaches I came up with:
Have some sort of check-out / check-in / locking system (although I don't know how to prevent people from keeping a file checked out "too long", and I don't want users to be frustrated by not being allowed to make an edit)
Have some sort of diff system that shows an other changes made when a user commits their changes and allows some sort of merge (but I'm worried this will hard to create and would make the site "too hard" to use)
Notify users of concurrent edits while they are making their changes (some sort of AJAX?)
Any other ways to go at this? Any examples of sites that implement this well?
Remember the version number (or ID) of the last change. Then read the entry before writing it and compare if this version is still the same.
In case of a conflict inform the user who was trying to write the entry which was changed in the meantime. Support him with a diff.
Most wikis do it this way. MediaWiki, Usemod, etc.
Three-way merging: The first thing to point out is that most concurrent edits, particularly on longer documents, are to different sections of the text. As a result, by noting which revision Users A and B acquired, we can do a three-way merge, as detailed by Bill Ritcher of Guiffy Software. A three-way merge can identify where the edits have been made from the original, and unless they clash it can silently merge both edits into a new article. Ideally, at this point carry out the merge and show User B the new document so that she can choose to further revise it.
Collision resolution:
This leaves you with the scenario when both editors have edited the same section. In this case, merge everything else and offer the text of the three versions to User B - that is, include the original - with either User A's version in the textbox or User B's. That choice depends on whether you think the default should be to accept the latest (the user just clicks Save to retain their version) or force the editor to edit twice to get their changes in (they have to re-apply their changes to editor A's version of the section).
Using three-way merging like this avoids lock-outs, which are very difficult to handle well on the web (how long do you let them have the lock?), and the aggravating 'you might want to look again' scenario, which only works well for forum-style responses. It also retains the post-respond style of the web.
If you want to Ajax it up a bit, dynamically 3-way merge User A's version into User B's version while they are editing it, and notify them. Now that would be impressive.
In Mediawiki, the server accepts the first change, and then when the second edit is saved a conflicts page comes up, and then the second person merges the two changes together. See Wikipedia: Help:Edit Conflicts
Using a locking mechanism will probably be the easiest to implement. Each article could have a lock field associated with it and a lock time. If the lock time exceeded some set value you'd consider the lock to be invalid and remove it when checking out the article for edit. You could also keep track of open locks and remove them on session close. You'd also need to implement some concurrency control in the database (autogenerated timestamps, perhaps) so that you could make sure that you are checking in an update to the version that you checked out, just in case two people were able to edit the article at the same time. Only the one with the correct version would be able successfully check in an edit.
You might also be able to find a difference engine that you could just use to construct differences, though displaying them in a wiki editor may be problematic -- actually displaying the differences is probably harder than constructing the diff. You'd rely on the versioning system to detect when you needed to reject an edit and perform a diff.
In Gmail, if we are writing a reply to a mail and someone else sends a reply while we are still typing it, a popup appears indicating that there is a new update and the update itself appears as another post without a page reload. This approach would suit your needs and if you can use Ajax to show the exact post with a link to diff of what was just updated while User B is still busy typing his entry that would be great.
As Ravi (and others) have said, you could use an AJAX approach and inform the user when another change is in progress. When an edit is submitted, just indicate the textual differences and let the second user work out how to merge the two versions.
However, I'd like to add on with something new you could try in addition to that: Open a chat dialog between the editors while they're doing their edits. You could use something like embedded Gabbly for that, for instance.
The best conflict resolution is direct dialog, I say.
Your problem (lost update) is solved best using Optimistic Concurrency Control.
One implementation is to add a version column in each editable entity of the system. On user edit you load the row and display the html form on the user. A hidden field gives the version, let's say 3. The update query needs to look something like:
update articles set ..., version=4 where id=14 and version=3;
If rows returned is 0 then someone has already updated article 14. All you need to do then is how to deal with the situation. Some common solutions:
last commit wins
first commit wins
merge conflicting updates
let the user decide
Instead of an incrementing version int/long you can use a timestamp but it's not suggested because:
retrieving the current time from the JVM isn't necessarily safe in a clustered environment, where nodes may not be time synchronized.
(quote from Java Persistence with Hibernate)
Some more info at the hibernate documentation.
At my office, we have a policy that all data tables contain 4 fields:
CreatedBy
CreatedDate
LastUpdateBy
LastUpdateDate
That way there is a nice audit trail on who has done what to the records, at least most recently.
But most importantly, it becomes easy enough to compare the LastUpdateDate of the current or edited record on the screen (requires you to store it on the page, in a cookie, whatever, with the value in the database. If the values don't match, you can decide what to do from there.