I want to see a sequence of diffs between consecutive (non-identical) revisions of the same file in a mercurial repository. I can obviously do that by parsing the result of hg log, extracting the changesets, then reading those two lines at a time and issuing hg diff -r $first_changset -r $second_changeset in a loop.
But - is there a more straightforward/elegant/graphical way of achieving the same?
Note: Not annotate though - at least not what it does by default. I want to be able to see all changes of the same changeset bunched together.
The quickest way to do this is with hg export, e.g.:
hg export -r reva:revb
This will actually give you an importable patch, but the extra meta information is often helpful.
The most general solution with the most configurable output is hg log with templates, e.g.:
hg log -r reva:revb -T '{diff()}\n'
The diff() template function takes optional arguments to specify include and exclude patterns. See hg help templates for details.
Note that this also works with -G and will draw a dependency graph alongside the diffs. Even when the graph is linear, this can help in finding the beginning and end of a diff. Obviously, you can also add further information to the template, such as revision number, hash, commit message, and author.
Normally, hg diff -c is intended for showing the diffs made by a revision, but unfortunately that does not work when you have multiple revisions.
Related
Is there any API in libgit2 which supports git-diff-tree "--cc" option ?
I want to know if a merge is clean or not (without merge conflict). Comparing patches from git_patch_from_diff() between two parents can differ sometime even if there is no change seen from git log -p --cc --merges <commit>.
When showing merge conflicts, git show defaults to this “compact combined” option, which displays only conflicts. That’s why most merge commits are empty.
I have a project, hosted on launchpad, which contains a fairly user-specific configuration file.
Once the project is initially checked out, obviously this .cfg file should also be downloaded. However, further updates (via "bzr update") would ideally not alter this .cfg file, as the user would have made their own edits to it. These edits would be overridden / merged should (with potential conflicts) I push an update using the code with my own .cfg file - I don't want this to happen!
What's the best practice to avoid this? I can't really "bzr ignore", as then any future users checking out via bzr would then not have the .cfg file.
I could, of course, replace my .cfg file with the "stock" one each time I do a commit, but this seems a bit clunky.
Or equivalently clunky, supply the .cfg file separately.
What I'm looking for is a "single-shot" download, but never update subsequently.
Any advice?
This is a tricky problem, because version control systems in general are not engineered to have the fine-grained commit strategies needed for this approach. If you were operating in a controlled environment, you could use plugins or hooks to exclude certain files from commits etc., but that doesn't seem to be an option here. I'll add that bzr ignore won't help you, either, because it only prevents files from being added; it doesn't prevent commits or checkout of those files.
What you can do is generate the config file during build/setup/installation if it doesn't already exist. Something like:
#!/bin/sh
if [ ! -e configuration.cfg ]; then
cp etc/configuration.cfg.in configuration.cfg
fi
Here, you'd check in etc/configuration.cfg.in normally and run the above script at build/setup/installation (this could also be automated by a post_change_branch_tip hook in a controlled environment). You'd put the original in a different directory so that there's less of a risk of it getting edited by accident.
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
Specifically I have a repository setup in Launchpad. I need to remove this repository but didn't find any link to do that from launchpad website. I am wondering whether I could do it on my local branch using "bzr". Or I am missing something from the launchpad website to remove it.
To have your entire project deleted from Launchpad, you have to post a "question" on this page:
https://answers.launchpad.net/launchpad/+addquestion
Yeah it's weird. But this seems to be the official way. If you search for the keywords "delete project" on this page you will find many many similar requests:
https://answers.launchpad.net/launchpad
Make sure to include a detailed explanation why you want to do this and that you are aware of the consequences. Otherwise you will get a response along the lines "the community might still use the source code you want to delete" and so on.
Of course they are right, and you should carefully consider whether you really want to remove code that other folks might be using and linking to.
If you are sure you want the project gone, then you can reduce the turnaround time with the Launchpad team by first deleting all your branches. You might not be able to delete the trunk, in that case you can try to force-overwrite it with an empty branch, using these steps:
bzr init empty
cd empty
touch empty.txt
bzr add
bzr commit -m 'dummy commit'
bzr push lp:PROJECT --overwrite
Of course, replace PROJECT with the name of your project. All these steps are necessary to empty the branch. You cannot simply push an empty branch, Bazaar will tell you that No new revisions or tags to push. and the branch will be untouched. You need a completely new revision, like the dummy revision in this example.
If your project has no meaningful source code in it, the Launchpad team should not have any objections to delete it, so you can reduce the turnaround time.
Is it possible to emulate the behavior of 'git stash' when using fossil/bzr?
Basically I'm interested in handling the following workflow:
at some point the source code tree has state X, it is commited
I proceed to writing new code, I write it for a while and I see the
opportunity of a refactoring
I can't commit at this point, because the change I've started to make is not
completed, it is not atomic yet
at this point I would do 'git stash', would save the current work and would
get back to state X
I would do the refactoring and commit, source code now has state Y
I would merge source code in state Y with code in stash, complete the change
to make it atomic, then commit once again, pushing the source code to state Z
I think that generally it is possible to emulate this scenario when using
another SCM by branching the code in state X instead of doing 'git stash',
doing the refactoring in that branch, then merging the branch back into the
main one. But I'm aware that branching is not always a cheap operation. So are
there any better particular approaches that eventually rely on specific
features of fossil/bzr?
Use bzr shelve and bzr unshelve commands.
You can use the patch command of your system.
First you make a "stash" by storing a generated diff as .patch file:
$scmtool diff > working.patch
then reset your working directory.
later, apply the patch with:
patch -p1 --dry-run < working.patch
and then this works, remove the --dry-run to apply the patch for real.
The stash command was implemented in fossil recently. You got to check out latest fossil executable you will see stash in the available command list.
Here is the link to the web help on its syntax.