I have a mercurial version control installation in my company. We have central repository and regularly pull changes from there.
Several files on my computer are marked as newer ones. But really they already exist there.
If I delete them physically, they became marked as removed. If I revert them, they become newer ones.
I already tried to reload this repository to newer place, but situation was repeated.
Can anyone help me?
It sounds a lot like you're pulling but not updating.
Pulling gets the changesets others have made, but they don't become active in your code directory until you update to them.
If I've misunderstood, could you post a sequence of commands, with the output you get, to demonstrate the problem?
If you miss icon overlays for some files, you can try TortoiseHG - Update Icons (or just cd forward and back some time, restart Overlay Icon Server...)
If you miss icon overlays for all files of some type, you may reach limit of overlays for your OS (bundle of different Tortoise* can give such effect)
Related
I've somehow marked a bunch of files as being "copy/renamed" instead of just marking them as new files.
I've also published these changes to our central repository and can cannot strip them out (we've already got some changes on top and I don't have the permissions/ability to fiddle with the central repository anyway).
Context:
I've actually done it to a whole bunch of files, but here's an example of what I did to one: I've copied a file called "Labels.properties", to a new file called "Labels_ja.properties" (the new file contains a subset of the original properties, and eventually all the values will be translated to a different language). The "Labels_ja.properties" file has been marked as a copy/rename of "Labels.properties" (the only way I've been able to see exactly what's happened is by looking with SourceTree, which shows "File copied/renamed from Labels.properties").
Our environment is a sort of central repository with automated "pull request" style merging tools built on top, so solutions involving all our developers magically knowing exactly how to drive Hg in order to resolve these conflicts aren't going to work - it's the scripts that are getting the merge conflicts.
These copy/renames are causing a lot of hassles: when people touch the original versions of the property files (they don't even know about the copied files yet) - it looks like Hg is trying to merge those changes onto the copies, but because the files are very different, those merges are failing with conflicts.
Problem:
What can I do to sort out all these merge conflicts that our automated merge scripts are getting?
Ideally, I'd like to go back in time and just mark all these files "new" - but there's no going back now that the changesets have been published.
Can I just make a big backout commit, then re-add the files (making sure that they are marked "new" and not "copy/renamed")?
I cannot think of a good solution. Even if you delete the files, Mercurial will still complain repeatedly when they get changed and merged. The simplest solution I can think of is moving the bad files into some "attic" directory where they don't hurt anyone and never touching them again. Then add the real files where they belong.
If I understand correctly, the problem is in fact that the developers are still based on a revision that does not have your move.
When they change the original file, an 'hg merge' will then smash together the changes from the developer and the changes to the new file in that new file.
I see a few solutions for this:
You can tell the developers to rebase their changes on top of the new changes. This will actually not work, since rebase will make the same mistake as merge.
The developers can turn their changes into patches and apply their patches on top of your changes. Their patches will refer to the original files, not the changed files, so this should work fine for the tools that merge later on.
The above flow can be done in a more sophisticated way using Mercurial Queues: import the existing developer commits as patches, then qpop all of these, update to your newer revision and qpush all of the revisions again.
Mark the head with your changes as 'closed' using '--close-branch'. However, if your tools are not equipped to handle this correctly (by ignoring the closed branch), this may cause issues. Branches are reopened when a new commit is done on top of the branch. So if you merge developer changes with the closed branch, it will open again.
I've thought this through and I think I understand the implications, but I wanted to get a sanity check because the caveats on https://www.mercurial-scm.org/wiki/ShareExtension are pretty general.
Specifically, the warning is "It's probably not a good idea to mix MQ and shared clones; if you do so, you should definitely avoid pushing/popping patches in one clone while another clone has patches applied."
However based on my understanding of how Mq works, it's only unsafe to push/pop patches (create/destroy history) if you have two shares whose working directory parent would be affected by such changes. That is, if you have two shares that are updated to separate named branches, pushing/popping patches from one should only have the effect on the other of creating/destroying history that is unrelated to the working directory and thus should NOT have any undesirable side-effects.
There will be small side effects, such as revision sequence number changes in some situations, but nothing that should jeopardize correctness or cause problems with the working directory.
Is this correct or am I missing something?
I'm not sure about this, but AFAIK if you end up having the exact same file content in both branches (repos), this might still wind up as shared storage and wreak havoc.
This is obviously not a definitive answer, but I just wanted to report back in case anyone else is interested in this situation. I've been running for several months now with multiple shares on a "central copy" of a large repo, with each share being dedicated to its own branch, and using MQ freely within each share. I have not hit any problems. History changes on other branches just look the same as pulls/strips would -- unrelated changesets being added, modified, and removed.
I've been having some problems with mercurial and kiln, maybe you can point me in the right direction. Sometimes when I commit the files they get renamed as Upper Case 'Assembly.NameSpace' will be changed to 'ASSEMBLY.NAMESPACE' and if I try to commit after making changes to them they appear as not being tracked (Side note I found out about the renamed files after I committed).
No matter what I do they just wont be tracked. I tried add using the console, using hg workbench and nothing seems to work. For it to work I need to forget the files, then commit, then add them again and then commit, which it really sucks for me.
Is it possible the files already exist in the repository with different case? "Case Folding" is a problem for any system that needs to work on both systems that are truly case sensitive and those that are only case retentive. Mercurial has done a lot of work to degrade as well as possible when a case folding problem arises and there's a lot of detail about it in the Mercurial wiki.
On what OS are you working?
When you do that initial add of the files are you using a wildcard or specifying them by name?
Do the files on disk actually change case when you add them? Mercurial only alters files in the working director (the stuff outside of .hg) on update, so it seem pretty much impossible that just doing hg add; hg commit would change the case of a file in the working directory.
Upgrading to latest version will fix the problem.
I'm new to mercurial, so may be my question is stupid.
Let say you made a mistake when you first started working on your code. For example, you putted
<!html DOCTYPE>
instead of
<!DOCTYPE html>
Now you want to change this, but not only to the latest revision, but to all revisions and versions of your page. Is this possible?
Omar, mercurial is about an immutable, historical record of you work. You can/should fix your error in all the heads, but it stays in history forever like a scientist's logbook.
There are plenty of ways to go about Editing History including histedit, convert, mercurial queues, and import/export/transplant, but none of them a strictly speaking Mercurial as it should be used, and all of them alter the hashids for all subsequent changesets which breaks the clones of anyone else working on the project.
Short answer: If at all possible make your peace with keeping the old data in history and correct it in a new revision.
I am new to the dvcs world. My company uses perforce and I'm not a fan so I thought I'd try to use mercurial as a front end. I set it up on a windows machine with TortiseHG, enabled the Perfarce extension, did a small checkout (limiting the target revision) and pulled for the rest. This seemed to be more robust than clone alone.
This seems to be working fairly well as I've been able to get up to change 8700 or so.
My problem is with an error in the perforce repo. During the hg pull command it hits an error abort: file path/to/file.pl missing in p4 workspace and rolls back the transaction.
Is there anyway to bypass or skip that file and force it to continue since this is not a file I care about.
Update:
According to the admin, the file in question was a symlink. Would that cause this kind of problem? If so, how do I/admin fix or bypass it?
Is it possible to check out just a part of a perforce repo rather than the whole thing?
The issue is with symlinks that are not supported out on Windows.
This is fixed in the current version of Perfarce, which should appear in TortoiseHG soon.
I suggest that you have someone check that the Perforce repository is actually in a sane state. There might be something broken which you triggered and the data of your company might be at stake, so someone should definitely look what is causing the problem.