Mercurial Pull Error - mercurial

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.

Related

Mercurial & Web Development: How to handle publishing/deployment?

At work we're moving from no SCM to Mercurial. It's a bit of a learning curve, but after messing with it for two days I definitely feel more comfortable with it.
I still have one big, unresolved question though in my mind: Once code is finished, how do we handle the actual deployment?
Should we be running a copy of Mercurial on the production (live) server? Or should we set rsync or something up to sync from the repo to the web directory? What's the best practice here?
If we do go w/ just pointing apache to the repo, I assume this is okay as long as we're careful not to hg update to a different, non-stable branch? That still seems a little dangerous to me though. Is there some way to force it to only switch to certain builds?
Or is pointing apache to the repo just a terrible idea and I should be doing something else instead?
On a related topic, I've also heard some talk about putting any upgrade scripts (such as schema changes for MySQL) under version control so they can be ran when the version is deployed. But how would that even work as part of the workflow? I wouldn't want to keep it w/ everything else, because it's a temporary one-time use script...
Thanks for any advice you guys can give.
I recently discovered the hg archive command, so I think we'll go w/ this instead. I've written a bash script that changes to the head of the 'production' branch then archives it to a predetermined destination. Seems to work.
I'd still appreciate any feedback you guys have as to whether this is a good idea or not.
I think pointing apache to the repo is definitely a bad idea, hg archive is ok if all you want is to take a snapshot of the dev files.
I find my development source files and a deployed application (even for a web app that doesn't need compiling) are usually very different, the latter being derived from a subset of the former.
I tend to use a shell script or a even a Makefile to "build" a deployed application in a subdirectory of the development directory, this could just be creating a directory tree and copying necessary files or could include compressing scripts etc.
This way you have to make a conscious decision whether or not to include a file in the deployed version, thus helping prevent accidentally leaving development utility files in an online application that could cause a security risk.
The only part mercurial plays is, for a major release I create a new named branch (eg: 1.5), development continues on the default branch. Subsequent bug fixes or patches can be transplanted to the release branch if necessary and if a bug fix release is made I tag the release branch with the new version (eg: 1.5.1).

Automatic shelve before pulling in Mercurial (with TortoiseHG)?

I have some changed files I don't want to commit (e.g. web.config). Before I pull and update to new changesets, I have to shelve them. After the pull & update, I have to unshelve them.
I'm currently using TortoiseHG. Is there any extension which can do this automatically?
I'd suggest something else: instead of always shelving and unshelving, you could use two different config files: one which is part of the repository and contains dummy/example data, and another one which each user really uses locally, which is ignored by Mercurial.
Check out this answer for a more detailed explanation what I mean.
The example I'm giving there is for Visual Studio, and I see from your other questions and answers that you're apparently using .net and Visual Studio, so you can just use my example exactly as written.
In Mercurial, just hg pull -u. Uncommitted changes are merged with the tip. Same result as shelve, pull/update, unshelve. With TortoiseHg a dialog will come up prompting for discard/shelve/merge.
You may get a merge dialog this way but that would be true with the shelving approach because unshelve may have to merge as well. From the command line you won't get a prompt if there are no conflicts. TortoiseHg may have an option to suppress the dialog if there are no conflicts, but I haven't checked.
I would try a few different things with this.
Regarding the Web.config file in particular, you might want to look at using local configuration files for overrides instead of leaving local changes uncommitted. (e.g. referencing an separate file that is in .hgignore). Projects I've worked on in the past did this to separate test/prod configurations from the settings for development, or vice-versa.
I don't think there is any extension which will do this for you, but you might be better off writing a quick batch or powershell script to do this workflow for you. On previous projects, I had a script which would do something similar in that it would do a pull/update/rebase to keep my changes at the tip (I was working with hg against an SVN server which made that important.)
I know I didn't answer your question directly, but I hope this helps!
Direct answer: https://pypi.org/project/hg-autoshelve/
But a dedicated repository for configuration files seems a better idea as suggested by
Christian Specht there

How can I make the commit message optional or a default in TortoiseHG (Mercurial)?

For some reason, I don't need to always include a message when committing with TortoiseHG (and VisualHG).
However, TortoiseHG (following the command line syntax) will not allow it. As it is painful to write a space or a random letter each time, I was wondering if there is a way to include a default commit message (such as "update"), or making this message optional (at least in the GUI), without recompiling TortoiseHG :).
If you know of a solution for TortoiseSVN or TortoiseGit, it probably applies as well for TortoiseHG.
I am aware of Does Mercurial support empty commit messages? but it doesn't provide an answer for TortoiseHG (for the CLI jk.'s answer seems to work).
As for "it's bad practice" comments, it is true in many cases but not all (imagine if Dropbox asked you each time anything changes to write a commit message)...
There's no way to do that in the current version of TortoiseHg. You would have to submit a patch upstream, modifying the behavior. You can see this for yourself in the TortoiseHg source code: https://bitbucket.org/tortoisehg/thg/src/0e6a0b894e70/tortoisehg/hgqt/commit.py#cl-670
You cannot have an empty commit message in Mercurial, it's simply not supported by the file format. Teaching TortoiseHg to use a template is another thing and you can try opening an issue for this.

Mercurial unreliable sub-repos. Any alternative?

I trying to like mercurial, but is driving me nuts.
I convert from SVN to it thinking in the promise of better workflows. Also, I use git in contract work, so I get the whole distributed idea. I choose mercurial for the promise of more simplicity and better windows support.
I'm a solo developer right now, working in a project that compromise 5 separate repos. Some commits are global and other locally applied to each one.
Normally, I commit each single repo, then fecth/push from the root.
But I found that:
The 2 head thing. Exist a way to disable that forever?
None of the GUI out there truly work for my workflow (I use MacHG, TortoiseHG, and try other half-attempts guis). I need to fall-back to command line for a workable push/pull behavior. No GUI understand subrepo, no understand that 2-head problem, so I need to fix/merge in command line.
But the worst of all, is that subrepo are tooo unreliable. Almost each 2-3 days I get "abort: unknown revision ****". Sometimes the hex value have a "+" at the end. Others not.
Sometimes is the ONLY change in the repo.
I don't wanna fix this behavior, I wanna a working replacement to subrepo, that let me:
Commit each sub repo
At the end, push+pull, automerge anything that make sense... and if work with the available GUIS better.
You are a bit confused in my humble opinion.
Mercurial and GIT are distributed versoin control, so the repository is always...the same.
You have your own copy of the repository with all the history. There is no "sub"-repo.
All repositories are "peer", and you can use clone them to do "sub" developement.
Every developer must have at least one peer repository.
Take a look at this good tutorial http://hginit.com/
Hope this helps

mercurial fails with a file named ---.config - any way around this?

We are just beginning to learn and evaluate Mercurial, due to an increasing number of nightmare merges, and various other problems we've had with SVN lately.
A client wants us to pull down a live copy of their site, do some SEO work on it, and push it back to them. They have no source control at all. I figure this is a great project to work on with Mercurial. Instead of putting it into our SVN and exporting when we are done, we'll use Mercurial... But right away it seems I have some problem :)
They have a file called ---.config which seems to cause our Mercurial to barf. It just can't commit that file. I've created the repo and committed everything else, but I just can't get this one file committed.
We are running on Windows 2008 x64 with TortoiseHG 1.0.
I suppose I could ignore the file since it is unlikely we'll need to work with it, but still - I'd like to learn how to use Mercurial a bit better. Is there a way around this?
EDIT: here is the error message:
('commit', GetoptError('option ---.config not recognized', '-.config'))
This happens when I hit the "commit" button in TortoiseHG with that file selected.
Not sure about hg, but most command line tools treat anything after a -- as a non-option. This is helpful if you have a filename that starts with -- or a wildcard that picks up such a file; try prefixing your filename or wildcard with --, e.g., hg command -- *.config.
The problem is that TortoiseHg did not escape filenames correctly when calling hg. When a filename starts with --, one must take extra care when using it on command lines.
I have just sent a patch which will hopefully make it into TortoiseHg 1.0.1, which is scheduled to be released later today.