Here's the steps I take:
Clone mercurial project at the head.
On local repository, perform hg status (no results), then hg in (no changes).
mvn clean install. Build is successful.
mvn release:prepare.
Get's to the point where it's excuting a push
[INFO] EXECUTING: cmd.exe /X /C "hg push http://remoterepo/hg.project"
[ERROR]
EXECUTION FAILED
Execution of cmd : push failed with exit code: -1
Your Hg installation seems to be valid and complete. Hg version: 1.8.4 (OK)
Doing a hg status I now have:
? pom.xml.releaseBackup
? release.properties
From my understanding is that this happens when it could be creating a branch on the remote repo and the fix is to make sure I'm on the head. I'm on the head.
I've done this several times before and now this happens. Let me reiterate, I cloned the head and I couldn't clone a branch if I wanted to as none exist.
Now what? How do I fix this?
Thanks for any suggestions.
Joe
I figured it out. It was a authentication thing. The Maven release plugin does not use the authentication details in <project>/.hg/hgrc but it DOES in /<Users>/<UserName>/.hgrc. After I updated my password everything worked just fine.
First of all what happens when you try to do an hg push yourself on the command line ? If everything's fine you definitively have a problem, otherwise the error message should help you determine what is going wrong.
If I were you, I would check if I have the right to push to the remote destination.
Is http://remoterepo/hg.project the real output or did you changed it for confidentiality reason ? If it's the real output, you should check your Maven configuration to put the real repository path.
Concerning the output of hg status after the steps, it's totally normal, Maven creates some file in the directory. You can add them to your .hgignore file so Mercurial won't show them to you. More information about that in the documentation.
Related
I'm getting the following error when attempting to commit to a Hg repository:
Z:\wormcard_maker>hg commit -m "asdf"
transaction abort!
rollback completed
abort: phases.new-commit: not a valid phase name ('')
This happens over multiple different repositories and has survived re-cloning the repository and reinstalling Mercurial. I can commit to the repository fine from a different computer (running Linux).
I'm running Hg 4.8 as distributed with TortoiseHg 4.8 on Windows 7.
In TortoiseHg just set the "File - Settings - Commit - New Commit Phase" option.
I tried using the THG setting but it didn't work; just kept producing the same error.
(While doing this I noticed that the THG dropdown for the phase choices had a bunch of blank lines in it; so I think THG was confused.)
Instead I manually edited my HGRC file and made sure it contained:
[phases]
new-commit = secret
which worked.
You could obviously use draft, etc. in place of secret.
Neither of the other answers worked for me - even though I had new-commit = secret in the HGRC it still produced the error.
The workaround I found was to do this:
hg ci -m "message" --config phases.new-commit=secret
which did work, apparently by overriding whatever invalid phase name hg was trying to use. Even though I don't know why.
I assume this would work with other comments, not just ci (aka commit).
https://www.mercurial-scm.org/guide please visit this link.....right now i successfully install mercurial but next step not i am clear.....
Initialize the project
Now you add a new folder in which you want to work:
$ hg init project
Add files and track them
$ cd project
$ (add files)
$ hg add
$ hg commit
(enter the commit message)
add file means i dont know...can u explain please
now i am using ubuntu....
mercurial installation step1:
embdes#embdes-laptop:~$ sudo apt-get install mercurial
[sudo] password for embdes:
Reading package lists... Done
Building dependency tree
Reading state information... Done
mercurial is already the newest version.
The following packages were automatically installed and are no longer required:
libopenal1 wavpack kdelibs4c2a libdc1394-22 mppenc vorbis-tools libxvidcore4
libldns1 libsvga1 kdelibs-data mplayer kdemultimedia-kio-plugins liblualib50
libkcddb4 mp3gain vorbisgain speex libmp3lame0 faad libavahi-qt3-1 icedax
freepats ffmpeg libao2 liblzo2-2 libavfilter0 flac libev3 timidity libqt3-mt
liblua50 timidity-daemon libunbound2 libavdevice52
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 261 not upgraded.
embdes#embdes-laptop:~$
step:2
embdes#embdes-laptop:~$ hg init project
abort: repository project already exists!
embdes#embdes-laptop:~$ cd project
embdes#embdes-laptop:~/project$ hg add
embdes#embdes-laptop:~/project$ hg commit
nothing changed
embdes#embdes-laptop:~/project$ hg init
abort: repository . already exists!
embdes#embdes-laptop:~/project$
This is the output from my commandline. Please correct me if I have done anything wrong.
The android project I develop will reside in the following directory,
/home/embdes/workspace
The following is the android sdk directory
/home/embdes/project/android/android-sdk/platform-tools/
how to install mercurial?
how to use android engine example project in my eclipse?
I am new in using commandline, so please help me in clearing above two doubts.
Thanks
You need to create files that are going to be version controlled. It is that simple.
You will find a full step-by-step tutorial at hginit
For instance, after an hg add, you need an hg commit:
There’s still one more step… you have to commit your changes. What changes? The change of adding all those files.
Why do you have to commit?
With Mercurial, committing says “hey, the way the files look right now—please remember that.” It’s like making a copy of the whole directory… every time you have something that you’ve changed that you sorta like, you commit.
When you issue the init command you are telling mercurial to track changes within the directory for a list of files... with the add command you tell mercurial which are these files.
By issuing the add command without any parameters you're telling mercurial to revision-control ALL the files within the "project" directory (recursively).
At any given time you can "forget" a file... and it will still be within "project" (directly or not) but mercurial won't care about any changes to the file.
You have to first get a basic understanding of what mercurial is for. Mercurial is a version control system which can store the changes you make your files. In your commandline output it is obvious that you have no files inside the,
/home/embdes/project
directory. That means you have made no change. Then what will mercurial store?? So only it says nothing has changed. You just create new files or directories there. Then do hg add. You will see the difference :)
I created a repository on a remote machine using:
hg init
hg add
hg commit
The repository was created.
I cloned the repository on a local machine with no errors reported; The files seem to be there
Now I'm trying to make a clone of the clone (as a working copy) using:
hg clone "path to original clone"
It returns:
destination directory: "name of repository"
abort: No such file or directory: "path to original clone"/.hg/store/lock
What am I doing wrong?
Thanks
What filesystem is used on the partition where the main repository is ?
Actually, when Mercurial is doing some operations, it needs to lock the repository. For doing this it creates a symbolic link to an nonexistent file, when the filesystem supports it, in the .hg repository, telling every other processes that the repository can't be modified at this time. When symbolic links aren't supported by the filesystem, a normal file is created.
However, there's some problems with some FUSE filesystems, typically SSHFS with the follow_symlinks option activated. FUSE reports that he knows about symbolic links, but since SSHFS follows the symbolic link and the file doesn't exist, the "state" of the link is marked as unknown thus Mercurial thinks the repository isn't correctly locked and abort the operation.
I see you're using Cygwin, so maybe it's the same kind of problem with tools designed for UNIX on a windows filesystem. It's a strange, coworkers of mine are using Mercurial via Cygwin just fine.
I don't know if it's the case for you, but I lost nearly half a day on this problem. Maybe this answers can help some people in the future.
Please paste in the actual command that's failing and the output including the actual path to the clone that you're cloning. When you do the clone use --debug and --traceback too.
As a workaround you can can always try hg init newclone followed by hg pull -R newclone pathtooriginalclone, which is effectively equivalent except it doesn't use local hardlinks when possible.
Before explaining my problem let me tell you the Mercurial setup,
We have the following repos,
RELEASE
DEVELOPMENT
BUGFIX
All the above repo are running on a central server using IIS and hgwebdir.cgi
Now coming to the problem,
I clone a local repo from DEVELOPMENT repo.
I make changes to the clone and commit (Not push).
I make a bundle from the clone and pass the bundle to QA who has cloned the RELEASE repo.
Now I try to apply the bundle to the RELEASE repo clone using hg unbundle
I get an error, abort: error: ftp error: no host given
What am I doing wrong? Can you give solution to the above problem keeping a Windows setup in mind?
It really sounds like you have a syntax error in your unbundle command. The normal usage is just:
hg unbundle c:\path\to\the.bundle
there's no ftp involved unless you're trying to use a ftp:// URL which isn't supported. Is it possible you have a directory named ftp and the parser is mistakign it for a component in a ftp URL?
Also, most folks wouldn't use bundles in the scenario you're describing. They'd just do:
hg push URL-or-file-path-to-QA
and push direct to QA's own repo (not to RELEASE)
People generally use bundles only when a network connection isn't possible or practical.
I experienced the same problem, I don't think hg likes uncs.
I mapped \server\DevSourceCode\Mercurial to R: and it worked fine, see below:
R:\Repositories\myproj>hg unbundle \\server\DevSourceCode\Mercurial\ChangeBundles\myproj_changes.hg
abort: error: ftp error: no host given
R:\Repositories\myproj>hg unbundle R:\ChangeBundles\myproj_changes.hg
adding changesets
adding manifests
adding file changes
added 0 changesets with 0 changes to 139 files
(run 'hg update' to get a working copy)
I use an ant file to build a java project in mercurial through hudson.
The mailnine has a hudson job running just fine.
Recently a new branch was created and pushed to the server by commnd line:
hg branch newbranch
hg commit
hg push -f
The mainine does not contain these changes and still builds fine.
I have set up a new job with the same setting as mainline (in fact copied mainline job in hudson), and specified the newbranch.
However, the newbranch job builds code identical to mainline.
If I commandline clone the repository and switch to the newbranch everything looks as expected. This seems to be a hudson configuration glitch unless my merqurial skills are off course.
I have also tried to set up the job from sratch with settings identical to mainline with the addition of the newbranch specification without any luck.
What am I missing?
Anyone any ideas?
Try putting the branch in the URL to clone like:
http://server/path/to/repo#newbranch
or
ssh://user#server//path/to/repo#newbranch
You can see the full syntax for branch-in-repo-url using hg help urls
URL Paths
Valid URLs are of the form:
local/filesystem/path[#revision]
file://local/filesystem/path[#revision]
http://[user[:pass]#]host[:port]/[path][#revision]
https://[user[:pass]#]host[:port]/[path][#revision]
ssh://[user[:pass]#]host[:port]/[path][#revision]
Paths in the local filesystem can either point to Mercurial repositories
or to bundle files (as created by 'hg bundle' or 'hg incoming --bundle').
An optional identifier after # indicates a particular branch, tag, or
changeset to use from the remote repository. See also 'hg help revisions'.
One issue with cloning a job is that the 'cloned' job is created as soon as you hit the clone button. While you are still configuring the cloned job, it may hit a build trigger like an SCM polling event that causes it to kick off before you have fully configured it.
I believe this was fixed in later versions of Hudson, but cannot find the changelog entry for job cloning. The same issue existed for cloning a slave configuration, and the problem was fixed in Hudson 1.319.