I have a "ghost zombie conflict" in my repositories.
Once upon a time there was a conflict whereupon me and my colleague modified the same lines in a certain file. No biggie, stuff like this happens. I resolved the conflict like I always do (I believe this to be the correct way, please correct me if I'm mistaken) by editing the result file so that the content makes sense and the conflict markers are gone, then darcs rec.
I have a couple of branches in different places, in development, testing and staging for instance. Whenever I apply the changes (or pull for that matter) the conflict is reintroduced (hence zombie). Darcs warns about a conflict, throws a bunch of markers in the file and I have to manually go and resolve the conflict again. The problem is that after I've removed the unnecessary parts, darcs wh shows no changes in the file (hence ghost)!
I'm completely at a loss as to 1) what happened 2) how can I fix it and 3) how can I prevent it in the future.
Related
I'm reading the NPM docs about package-lock.json and my interpretation is that a committed change to it can never cause issues in the deployed version.
During the roll-out we run npm install which creates (or overwrites) the lock file anyway. In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.
However, I haven't been successful convincing my team that it is so. They feel uneasy relying on the statement above (not contradicting it nor arguing against it, just not entirely convinced to the degree that they would bet a testicle on it).
Is it at all possible that package-lock.json might affect the actual installation?
Since I'm new with the company, my track record of 10+ years has limited impact. And I'm myself humbly considering that even though the lock file never caused me any issues before, my experience might be irrelevant if the local environment is configured in a way I'm not familiar with yet. So I'm too cautious to bet my reputation as we're about to make a very important release.
In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.
Maybe I am interpreting your statement wrong but package-lock is a pointer for future installations in a way. See the general documentaion on lock files (different link than the one you shared), following statement from the above doc might be helpful:
This file describes an exact, and more importantly reproducible node_modules tree. Once it’s present, any future installation will base its work off this file, instead of recalculating dependency versions off package.json.`
A read on following discussion on this topic might be helpful to you too. Thanks!
I try to merge branch A to branch B. Both in A and B had inconsistent tabbing previously due to team work, but we fixed and the current version on A and B has the same tabbing. Now, when I try to merge the two branches I have merge conflicts (not due to the tabbing). When I try to solve the conflicts with meld (also tried with kdiff3, same thing) as mergetool, the LOCAL and REMOTE is with the same tabbing but the BASE is with the old tabbing as shown in the picture:
Why does this happen?
It is hard to go through the tabbing fixes and also look for the conflicts during mrege. How can this be fixed?
As the image shows the old tabbing in your BASE comes from the first common ancestor of the modified file in branch A and branch B. Then everything is going as expected.
You can try to add a hunk from any side (LOCAL or REMOTE) over the hunk with the old tabbing in BASE, since it is an outdated hunk. It should clarify the conflicts resolution.
Can you provide the full image or the BASE, REMOTE and LOCAL files from the conflict in something like a gist?
this answer should be a comment, but i don't have reputation enough
IntelliJ has a "safe write" option (quotes theirs, for some reason) which, on save, instead of simply updating the file, writes to a temporary file, then deletes the original, then renames the temporary file to the original's name. I hear that vim also does this.
I know this causes problems with programs that are watching the file. Sometimes such programs see the delete, but never see the update, for example.
But what advantages are there? IntelliJ's docs say that there are advantages that would be lost if you turned it off. There must be some reason this option is the default.
It took me a looong time to figure out this was how intellij operated and that it was causing some chronic issues I was facing, and took me even longer to figure out it was an option I could turn off. Now that I have that option, I'd like to know if the cure is worse than the disease, so to speak.
The safe write prevents you from data loss in case something goes wrong during the update. Just think of your computer or Intellij crashing while you are saving the file. You might lose the file completely then. But with safe write you would lose your recent changes only. After the updated version of your file is written to disk without errors, the old version can be replaced. This way you have a valid file version at any point of time during the update process, so no crash or whatever could make you lose all your work on that file. The worst thing which could happen is the loss of your recent changes.
We have a C++Builder XE project (VCL Forms Application) that has a few dozen forms and units in it. Whenever a file belonging to the project is added, deleted, or renamed, the IDE should do two things:
A call to USEFORM macro is added to or altered in the Project Source file (ProjectName.cpp) if the affected unit is a form or frame
A CppCompile element in the project file (ProjectName.cbproj) is added or altered
However instead of just doing the necessary changes, the IDE shuffles some of the existing USEFORMs and CppCompile records, even if they aren't affected by the changes. If I add a Unit (cpp and header file), the USEFORMs are shuffled even when that wouldn't require any changes to the Project Source, only to the cbproj-file.
I don't see a specific pattern on how the new order is formed. If I edit or rename a single unit, about half of the USEFORMs seem to change position and just a couple or none of the CppCompile records. If a change is made to a copy of the project in two different machines, most of the changes seem to be similar, but not all. This indicates that the reordering is not random.
The behaviour causes problems when using Subversion to merge changes, because it forces to manually resolve conflicts inflicted by the changing order.
So the question is: What might be causing the foregoing behaviour and how to get rid of it?
I haven't been able to find a proper solution to the problem, but here's a simple method for making it slightly less annoying:
Adopt a policy of never committing the random IDE-generated changes to the version control repository. Whenever you make changes to code that trigger mixing up the files, revert all unnecessary changes in ProjectName.cpp and ProjectName.cbproj. At this point it is still fairly easy, as you know which parts of the files actually should have changed. That way, the manual labour is carried out when it still requires the minimal amount of work. Additionally, the work has to be carried out only once, in contrast to leaving the changes untouched, in which case the work has to be repeated every time someone merges the changes.
I installed Darcs a few days ago and have a doubt.
I am the only programmer and I usually work on two or three instances of the application, making new feautures. The problems cames because this instances modify the same source code file, so when I finished them and send to main repository they make a conflict.
Is there any way to deal with this? Can I write the same file in multiple instances without making conflict when pushing to main repository?
thanks
First of all when changes occurs at different places of the file there is generally no conflicts when merging. When two patches can be merged without conflicts one says that they commute. In your case it happens that you've modified the same part of the file in two different branches. In this case darcs don't allow you to "push" the second patch that makes the conflict.
There is two ways to resolve such a confilct, but you have to start to locally merge the both patches to get the conflict in your working repo. To do this just pull the patches from the main repository. Then you have to edit the offended file and resolve the conflict.
The first way is simple and the prefered solution, you have to "amend-record" the patch that is not yet on the main repository (look at the usage of the "darcs amend-record" command).
The other solution is to record a resolution patch, by calling "darcs record" and then pushing both the conflicting patch and the resolution patch. This solution tends to complicate the history and can make some later operations longer. However when the branch has been heavily distributed this solution becomes needed.