hg record is very useful for splitting the changes in your working copy into multiple commits.
When you run hg record, it will ask you for each modified file:
examine changes to '<file>'? [Ynesfdaq?]
and if you say yes, then for each change in the file:
record change X/Y to '<file>'? [Ynesfdaq?]
However, I often find that I could complete the operation much more efficiently by automatically being shown all changes (i.e. as if I said y to every question of the first form). Basically, I want to see all changed hunks and make yes/no decisions about them, without the distraction of intervening examine changes to <file>? questions (to which I would always say yes).
Is there to get hg record way to do this?
I find the CRecord Extension invaluable for this. It gives a curses based UI for the record command, and allows you to get a much better overview of all your changes. It also allows you to select down to line resolution, rather than just each hunk.
Related
I use the "show annotation" functionality quite often. Now, I accidentally crushed the svn and solved it by making a re-commit of everything. Now, every time I use the "show annotation" function, it shows this last commit on every line.
Can I revert this somehow?
I'm assuming you didn't kill the entire SVN and "solved" that by starting over from rev 1. I'm assuming some intermediate revision got corrupted and you had to touch and commit every file in a new revision, but older revisions are visible and accessible in the SVN history. The Annotations feature, and Plan B both rely on that.
What the textbook offers
Excluding a single mid-range revision is not possible, given a certain history. You can only exclude head or tail ranges by specifying revisions other than 1 for the "From" and HEAD for the "To".
Say the "repair" revision you want to exclude is r1000. To exclude it, you can choose to consider either (from-to) r1-r999 or r1001-HEAD, leaving out r1000. So you are confined to either viewing the changes before or after the repair.
You can read up on the possibilities and options of what's internally called svn blame in the SVN documentation.
Plan B
Now, that's not really satisfying, I imagine. Here's something else you can try, but please create a backup of your repo first.
With the help of the SVN history viewer, or log viewer, find the last revision before the corrupted revision, say r997.
Make a branch based off that last good revision.
Then delete or move the current trunk, using the corresponding SVN commands.
In the last step, move or branch(=copy) the branch back to the trunk location.
You have effectively cut out the corrupt revisions. The branch-now-trunk has a "hole" in its revision numbers, because branching off r997 created a new revision younger than the corrupted and repairing revisions. Afterwards, showing annotations on that new trunk will work like before, but wont include the corruption and your "repair".
Here, I made an illustration for you:
This operation can screw up some ancestry operations like merging, but I've done it successfully before, even with large merging operations later on, so you might as well try it, too. Good luck!
I have a project in which I've set up a bitbucket repo using mercurial.
We're actually 3 to work on it, so we're using branches.
When we did merges, we did them quite randomly so many times it failed.
Actually, I'm using Meld, and I don't really know in "which" part of the repo I have to choose which part of the source code I want to merge.
So, when I do merge, where should I do it ?
I'm not really sure if I have to do it on local, base or other, even though I know local corresponds to my last modifications, other corresponds to the last modifications of the branch I want to merge, and well, actually I'm not really sure about what is other ...
On careful review, I have found it out. You want to merge into local
Please correct me if I'm wrong but I am pretty sure after doing some tests
Local
The correct place to merge change to. The local files that will result from the merge. This will likely contain a mix of some auto-merged lines already.
Base
Where you are merging into.
Other
The merges you're pulling
This may not be the "right" answer, but when in doubt, I make them ALL match by making them look ALL merged 'correctly' (sometimes I have to discuss with my coworkers what the 'correct' look is based on their changes).
By doing this, I ensure the merge will be successful because meld cannot and will not actually change upstream data in mercurial. So there's no downside. For the life of me I also cannot tell which pane to merge into (mostly because the term 'base vs local' is ambiguous). So this is kind of an odd way to do it, but it works
I am writing a wrapper script where I will be doing a mass integration to change the branching structure. For now we have a structure like this:
//depot/product/component-1/...
//depot/product/component-2/...
...
//depot/product/component-n/...
and we are moving to
//depot/product/release/component-1/...
//depot/product/release/component-2/...
...
//depot/product/release/component-n/...
I have written a wrapper script for doing a mass integration where every branch move is captured as a part of individual changelist. Like changelist 101 will have integ for component-1, changelist 102 will have for component-2 and so on. And at the end, it will submit all the changes. This is to narrow the submissions at component level.
My fear is if something bad happens in between and my script fails to submit or due to unforeseen reasons, integrations are in an intermediate state and I have to revert back everything to a state prior to running this script. How can I do that ? Is there a mechanism where I can persist the data before submitting somehow into perforce itself so that i can fall back to it?
When I say data, I mean output of
p4 files //depot/product/component-n/...#LabelTobeUsedForInteg
The constraints I have is that this script will be executed by multiple people doing their own set of integrations which is why I cant just dump the information in a text file locally. I need a solution where people having access only to perforce can get this persisted information in case they have to fall back and revert the submissions. Storing this information in DB is also out of question. :(
Is there a way to achieve this ? Thanks in advance. Really appreciate your help on this.
If you want all the integrations to happen or none, then this is what atomic changelists are for. Put all your integrations in one changelist and either it'll all get submitted or none of it will.
If you do want to do them separately, you shouldn't need to persist the output of the p4 files command. The label will still be on the old revisions after the integration so the p4 files command should still produce the same output.
If you really do need to persist the output, you could just check it into Perforce. Make some area like //depot/integration-records and check each file in to e.g. //depot/integration-records/component-n.txt as it is produced. You can put the addition of the file on the changelist that integrates component-n so that the presence or absence of the file would indicate whether the integration has been done or not.
during synchronisation with the CVS server, eclipse compares the content of the files (of course it uses internally CVS commands). But files without any content change are also shown as different, if they have another timestamp, because they are "touched". You always have to look manually per file comparison dialog if there was really a change in it or not.
Due to auto-generation I have some files that always get new timestamps and therefore I always have to check manually if they really contain any change.
At the eclipse docu I read :
Update and Commit Operations
There are several flavours of update and commit operations available
in the Synchronize view. You can perform the standard update and
commit operation on all visible applicable changes or a selected
subset. You can also choose to override and update, thus ignoring any
local changes, or override and commit, thus making the remote resource
match the contents of the local resource. You can also choose to clean
the timestamps for files that have been modified locally (perhaps by
an external build tool) but whose contents match that of the server.
That's exactly what I want to do. But I don't know how!? There is no further description/manual ...
Did anybody use this functionality and can help me (maybe even post a screenshot)?
Thanks in advance,
Mayoares
When you perform a CVS Update on a project (using context menu Team->Update), Eclipse implicitly updates the timestamp of local files whose contents match that of the server.
How are you doing this task in Perforce ?
Yes, you can't do that.
The only thing you can do would be:
shelve your file without reverting it
open the diff of your file, and remove any other changes that those you want to submit
submit the resulting file which contains only the part you wanted to
unshelve the shelved version of the file
get the latest revision of it, and resolve (P4 should be able to auto-resolve it)
Then you still have the file in checkout, with the other modifications.
You can't. As with some other version control systems, you operate on a per file basis. That is, a single file is the smallest entity / unit of work possible.
I'd think that they all act on the presumption that changes to a file are atomic (most good version control systems will even use a commit of multiple files as an atomic operation).
If you only want to commit some parts, you essentially have to create a copy of your modified file, where you reset all those parts that you don't want to change back to their original content/text. Or better yet, only change one thing at a time and eventually separately commit those changes.