Is the command described in the title reversible?
I tried searching the log (with hg log) and stripping the corresponding changeset, but no log was issued for this command.
Is the command described in the title reversible?
no, if you --clean, you'll lose all changes in working directory
I tried searching the log ... but no log was issued for this command
hg up does not affect repository in any way, it's a pure workdir command
Related
I am not understanding why Mercurial sometimes cannot find file when it does a log command, but it always finds it when I do a status.
For example:
hg status --change "1111" "path\to\file" -- Returns path to file
hg log -r "1111" "path\to\file" -- Returns changeset
But, sometimes it fails with a different changeset:
hg status --change "2222" "path\to\file" -- Returns path to file
hg log -r "2222" "path\to\file" -- Returns nothing
How can this be? If the file exists proven through the use of a status command, how can I not retrieve the changeset through log on some changesets?
Hidden in the documentation it seems like this solved my issue:
For performance reasons, 'hg log FILE' may omit duplicate changes made
on branches and will not show removals or mode changes. To see all
such changes, use the --removed switch.
Seems a little ridiculous that you have to specify this, especially when you already explicitly state the file.
I am currently attempting to set up an automated add/checkout/checking script using MS Visual Source Safe via command line. Online documentation is... lacking... and I was hoping that someone else had tried doing something like this in the past.
Before going any further, I am well aware that there are other, better alternatives to VSS, so please don't give "use SVN" as an answer.
The files I've got are a scripted version of our database schema, and looks like this in the repo:
$/project_name/DBScripts/servers/databases/object_types, where object_types are Tables, StoredProcedures, etc.
I am attempting to do the following:
1- Script all database object to files. This part is done and working correctly.
2- Add all new files to repo.
3- Commit all files that have changed. Make sure files do NOT remain checked out or read-only.
EDIT 2:
Removed old code again. Included current code below. Add works correctly, but the checkout command does NOT work on any files that were changed locally.
In this context, if I were to modify stored proc A, script it to file, then try running the batch commands below, all procs BUT A will be checked out.
I've included 2 examples of the checkout command. Neither is working...
set PATH=%path%;C:\Program Files\Microsoft Visual SourceSafe
set SSDIR=repo_path
cd DBScripts/server/database/StoredProcedures
ss cp $/project/DBScripts/server/database/StoredProcedures
for %%F in (*.*) do ss add %%~nF%%~xF -C- -I-N -K- -W
for %%F in (*.*) do ss checkout $/project/DBScripts/server/database/StoredProcedures/%%~nF%%~xF -C- -G- -M- -L+
ss checkout $/project/DBScripts/server/database/StoredProcedures *.* -C- -G- -M- -L+ -Vltemp
for %%F in (*.*) do ss checkin %%~nF%%~xF -C- -K- -P $/project/DBScripts/server/database/StoredProcedures -W
cd ../../../..
Note: SourceSafe's "-R" command is inconsistent. I'd rather loop through all subfolders manually and do "for %%F in (.)" commands.
Possible reason is the checkin command is executed before prior add/checkout commands are finished. Try checking if add is successful before the checkout command, and checking if checkout is successful before the checkin command.
When I commit changes in Eclipse, svn records my author name as the one that I entered the first time I committed changes in Eclipse (Alok). By author name, I mean the name that shows up when you run "svn log" or "svn blame".
However, when I commit changes from the command line, the Author Name is set to the username that I use to ssh to the repository (svnadmin). Is there a way to set the equivalent of Author Name/svn username independently of the ssh username from the command line when using svn+ssh? I have tried
svn --username Alok ci
but the username in this case is ignored, and the change is attributed to svnadmin.
It is by design that you cannot change the username for svn+ssh. If you could, you would be able to fake somebody else as the committer - when the SSH key would normally clearly identify yourself as the committer.
So if you want different committer names to show up with svn+ssh, you need to change something on the server:
Create separate remote users, and put your key into the authorized_keys file for the user you want to appear as committer. Alternatively,
Put command= lines into the authorized_keys file of the svnadmin user. The command should read /usr/bin/svnserve -t --tunnel-user Alok; optionally also with a --root option.
One workaround is to first enable editing of revision tags by putting a shell script like the following in hooks/pre-revprop-change
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
if [ "$PROPNAME" = "svn:log" ]; then exit 0; fi
if [ "$PROPNAME" = "svn:author" ]; then exit 0; fi
exit 1
Then, after the commit you can change the svn:author with
svn propset --revprop -r1234 svn:author Alok
This does not explain how eclipse is able to set svn:author at commit time without having a pre-revprop-change hook. This solution is a little unsatisfying because it allows any user to change the svn:author of any commit, it would be nice to know what eclipse is actually doing.
This should be a very simple thing to have run, but for some reason it won't work with my Mercurial repository. All I want is for the remote repo to automatically run hg update whenever someone pushes to it. So I have this in my .hg/hgrc file:
[hook]
changegroup = hg update
Simple, right? But for some reason, this never executes. I also tried writing a shell script that did this. .hg/hgrc looked like this:
[hooks]
changegroup = /home/marc/bin/hg-update
and hg-update looked like this:
#!/bin/sh
hg help >> /home/marc/works.txt;
hg update >> /home/marc/works.txt;
exit 0;
But again, this doesn't update. The contents of hg help are written out to works.txt, but nothing is written out for hg update. Is there something obvious I'm missing here? This has been plaguing me for days and I just can't seem to get it to work.
Update
Okay so again, using the -v switch on the command line from my workstation pushing to the remote repo doesn't print any verbose messages even when I have those echo lines in .hg/hgrc. However, when I do a push from a clone of the repo on the same filesystem (I'm logged in via SSH), this is what I get:
bash-3.00$ hg -v push ../test-repo/
pushing to ../test-repo/
searching for changes
1 changesets found
running hook prechangegroup: echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Remote repo is at 821:1f2656753c98
Remote repo wdir is at 821:1f2656753c98
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
running hook changegroup: echo "Updating.... `hg update -v`"
echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Updating.... resolving manifests
getting license.txt
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Remote repo is at 822:389a6c7276c6
Remote repo wdir is at 822:389a6c7276c6
So it works, but again only when I push from the same filesystem. It doesn't work if I try pushing to the repo from another workstation over the network.
Well, after going through the same steps of frustration as Marc W did a while ago, I finally found the solution to the problem, at least when remote serving is done with the hgwebdir WSGI script.
I found out that when using this kind of remote push via HTTP or HTTPS, Mercurial simply ignores everything you write into the .hg/hgrc file or your repository. However, entering the hook in the hgwebdir config does the trick.
So if the bottom line in your hgwebdir.wsgi script is something like
application = hgwebdir('hgweb.config')
the [hooks] config section needs to go into the mentioned hgweb.config.
One drawback is that these hooks are executed for every repository listed in the [paths] section of that config. Even though HG offers another WSGI-capable function (hgweb instead of hgwebdir) to serve only a single repository, that one doesn't seem to support any hooks (neither does it have any config).
This can, however, be circumvented by using a hgwebdir as described above and having some Apache RewriteRule map everything into the desired subdirectory. This one works for me:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/reponame
RewriteRule ^(.*)$ reponame/$2 [QSA]
Have fun using your remote hooks over HTTP :D
I spent some time researching this myself. I think the answer to problem is described concisely here:
Output has to be redirected to stderr (or /dev/null), because stdout
is used for the data stream.
Basically, you're not redirecting to stderr, and hence polluting stdout.
First of all, I want to correct a few comments above.
Hooks are invoked also when pushing over file system.
It is not necessary to keep the hook in the repo on which you want them to operate. You can also write the same hook as in your question on the user end. You have to change the event from changegroup to outgoing and also to specify the URL of remote repo with the -R switch. Then if the pushing user has sufficient privileges on the remote repo, the hook will execute successfully.
.hg/hgrc
[hooks]
outgoing = hg update -R $HG_URL
Now towards your problem.... I suggest creating both prechangegroup and changegroup hooks and printing some debugging output.
.hg/hgrc
[hooks]
prechangegroup = echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
changegroup = echo "Updating.... `hg update -v`"
echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
And also push with the -v switch, so that you may know which hook is running. If you still can't figure out, post the output. I might be able to help.
My problem was that my hgwebdir application ran as the "hg" user, but the repository was owned by me, so I had to add in this bit of config to hgweb.config to get it to run the hooks:
[trusted]
users = me
You need to have it in the remote repositiory's hgrc. It sounds as if it's in your local repo.
Edit: It also depends on how you're pushing. Some methods don't invoke hooks on the right side. (ssh does, I think HTTP does, file system does not)
Edit2: What if you push "locally" at the remote repo's computer. You might have different users/permissions between the webserver and the hgrc-file. (See [server] and trusted directives for hgrc.)
I had the same problem pushing from Windows Eclipse via http, but after capturing stderr, I found that the full path was needed to the hg.bat file. My hooks section now looks like:
[hooks]
incoming = c:\Python27\Scripts\hg.bat update > hg_log.txt 2>>hg_err.txt
Hope this helps someone else.
SteveT
Try turning on hook debugging to see why it's not running.
Likely a permissions issue or something like that.
took a while but I got it working.
I started with
[hooks]
tag=set >&2
commit=set >&2
the >&2 pipes it to standard error so remote consoles will show it.
when remote this should output in console if it is running
hg push https://host/hg -v
It wasn't.
I was using hgweb.cgi so I switched to hgweb.wsgi with no difference.
what I discovered is that some hooks don't get called on remote.
when I switched it to
[hooks]
incoming= set >&2
the hooks tag and commit don't seem to get called but incoming and changeset do get called. I haven't confirmed the others.
now that I got it working I switched back to hgweb.cgi and everything works the same.
Tthe reason I've found for this has nothing to do with redirecting stdout to stderr. As you may see in the wiki page it is not specified on the wiki's current version
https://www.mercurial-scm.org/wiki/FAQ#FAQ.2FCommonProblems.Any_way_to_.27hg_push.27_and_have_an_automatic_.27hg_update.27_on_the_remote_server.3F
The problem I've found is around permissions.
In my original setup, I had a user, lets say hguser with a repo on its home, and a script /etc/init.d/hg.init to launch hg serve. The problem being hg serve was being run by root, while most files under the repo pertained to hguser (some of them switched to root at some point, but it won't mind, since I'll correct them with chown)
Solution:
chown -R hguser:hguser /home/hguser/repo (to correct ALL files, back to hguser)
launch su hguser -c "hg serve ..." (in my case from /etc/init.d/hg.init)
changegroup = hg update -C under [hooks] in repo/.hg/hgrc as usual
Now it should work on push
PS: in my case, I rather update to the head of a specific branch, so I use hg update -C -r staging, to make the staging server update only to the head of the intended branch, even if the tip is from another branch (like development for instance)
BTW my hg.init script ended up like this: (notice the su hguser part)
#!/bin/sh
#
# Startup script for mercurial server.
#
# #see http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html
HG=/usr/bin/hg
CONF=/etc/mercurial/hgweb.config
# Path to PID file of running mercurial process.
PID_FILE=/etc/mercurial/hg.pid
state=$1
case "$state" in
'start')
echo "Mecurial Server service starting."
(su hguser -c "${HG} serve -d --webdir-conf ${CONF} -p 8000 --pid-file ${PID_FILE}")
;;
'stop')
if [ -f "${PID_FILE}" ]; then
PID=`cat "${PID_FILE}"`
if [ "${PID}" -gt 1 ]; then
kill -TERM ${PID}
echo "Stopping the Mercurial service PID=${PID}."
else
echo Bad PID for Mercurial -- \"${PID}\"
fi
else
echo No PID file recorded for mercurial
fi
;;
*)
echo "$0 {start|stop}"
exit 1
;;
esac
PS: due credit to http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html
I am creating some build scripts that interact with Perforce and I would like to mark for delete a few files. What exactly is the P4 syntax using the command line?
p4 delete filename
(output of p4 help delete)
delete -- Open an existing file to delete it from the depot
p4 delete [ -c changelist# ] [ -n ] file ...
Opens a file that currently exists in the depot for deletion.
If the file is present on the client it is removed. If a pending
changelist number is given with the -c flag the opened file is
associated with that changelist, otherwise it is associated with
the 'default' pending changelist.
Files that are deleted generally do not appear on the have list.
The -n flag displays what would be opened for delete without actually
changing any files or metadata.
Teach a man to fish:
p4 help - gets you general command
syntax
p4 help commands - lists the
commands
p4 help <command name> -
provides detailed help for a specific
command
http://www.perforce.com/perforce/doc.062/manuals/boilerplates/quickstart.html
Deleting files
To delete files from both the Perforce server and your workspace, issue the p4 delete command. For example:
p4 delete demo.txt readme.txt
The specified files are removed from your workspace and marked for deletion from the server. If you decide you don't want to delete the files after all, issue the p4 revert command. When you revert files opened for delete, Perforce restores them to your workspace.
Admitted - it takes a (small) number of steps to find the (excellent!) Perforce user guide online in the version that matches your installation and get to the chapter with the information you need.
Whenever I find myself in need of anything about the p4 command line client, I rely on the help Perforce have built into it. Accessing it could not be easier:
on the command line, enter p4
This gets you to the information Michael Burr has shown in his answer (and some more).
If you do not get a help screen right away, something is wrong with our client configuration, e.g. P4PORT is not set properly. You obviously need to fix that first.