Is there a way to do some checks before allowing a merge in Mercurial?
I have found the pre-update hook and have a script that runs before an update is allowed, by adding the following to ~/.hg/hgrc:
[hooks]
pre-update = ~/hg_pre_update.sh
But I'd like to run the check before allowing a merge as well, and currently it just allows the merge to go through without running my checks.
Background
In case there are alternative ways to solve the problem...
We have been having a number of problems with 'lost' edits under Mercurial. I've tracked down most of them now to the same underlying cause: someone has vim edit sessions open while either they or someone else does a hg update or merge. The editor warns the file has changed externally, the user ignores the warning and saves their changes.
When these changes are committed, for Mercurial there is nothing controversial. The user has simply reverted all the changes brought in with the last update and put in their own changes.
Some time later, we notice the code has gone walkabouts. Cue assorted insults flung the way of mercurial...
Set vim to autoreload changes if no local changes where done. (otherwise ask, or force a merge)
that's how I avoid such issues in any editor...
Sorry just worked out there is a pre-merge hook that works just the same as pre-update. I tried it before asking the question, but now just looking at my hgrc I realise I put the script being called for that hook to ~/hg_pre_merge.sh which doesn't exist.
I can't find the existence of pre-merge documented anywhere but still feeling like a bit of a muppet now.
Related
Running through the full loop for a scenarios-based workflow and noticed that the scenario once applied is NOT auto-deleted. What is considered best practice to prevent users from accidentally applying a scenario twice? Is it best to delete them afterwards? If so, why is auto-delete not enabled?
you could delete but usually I would add a flag called "applied" and filter my list of displayed scenarios by "applied" == false or something like that.
If you ever want to use your scenarios for metrics. E.g. how many scenarios have been applied / maybe write some stats to the scenario object on apply this data is all lost if you're deleting on apply. I believe that's also why it's not part of the workflow by default. The idea is that you should make that decision for your use case.
I've recently been asked by my supervisor to prepare a solution in which multiple pieces of logic throughout our application can be reverted back to an earlier piece of code while the application is live. In effect, I need to prepare something like a flag or an indicator that can be dynamically activated to switch all instances of code in our application, from the new version back to the old one.
The new logic was prepared by a new member of our team and we are concerned about memory leaks that will emerge once the code goes to production, and we want a solution in place that will allow us to turn those changes off and return to the original code if necessary.
if (new_code == ON)
{
New Logic
}
else
{
Old logic
}
This project was originally meant to help get rid of build and compile warnings during our build process so it affects code ranging from function arguments to variable declarations, so there's no one single type of code that will be affected. We are running off a tuxedo stack but implementing a tuxedo config file to effect this change isn't recommended according to one of our senior developers. I'm not aware of a similar solution, though.
Any ideas? Thanks!
Would it work? Sure. Is it a good idea? No. You now have the risk of the new code, plus the risk of bugs in your switch code, plus the risk of what happens if you switch from one to the other in mid-run. You shouldn't be doing this, its far more likely to cause trouble than just deploying the changes directly.
What you should do- if you're really concerned about it, don't deploy it. Put it through additional testing until you're comfortable with it. Then when you do deploy it, have a plan to roll back to a previous version without these changes if something slips through testing.
call the function using function pointers.
make an API to change the function pointer to old or new depending on your need.
I would like to make a trigger that only executes for a single user(myself). The reason, is so that I don't "break the build".
Longer explanation: I'm trying to sandbox a Clearcase trigger to automatically apply an attribute to an element when it is checked in, and I don't want to accidentally create a trigger that applies to all developers and potentially ruin everybody's day with the prototype(what works on the first try?).
I see the -nus/ers option which seems to exclude users in the list. I suppose I could comma separate a list of all users, excepting myself. Is this what I'm looking for?
The best sources of information about triggers are listed here, and then EV (Environment Variables) are mentioned in mktrype man page.
Check for isntance:
CLEARCASE_USER
The user who issued the command that caused the trigger to fire; derived from the UNIX or Linux real user ID or the Windows user ID.
If the user id somehow doesn't work, you could consider other environment variables:
CLEARCASE_SNAPSHOT_PN
Your script can control if the user id is yours, and if not, abort.
The path to the root of the snapshot view directory in which the operation that caused the trigger to fire took place.
If your script detect that the path isn't the exact one expected (ie your snapshot view from which your triggered your script), said trigger script would abort.
I'm making use of an open source project that is changing quite frequently. It is necessary for me to always have the latest version with all changes and bug fixes.
The source code has been adjusted to make it do what I need. So it now contains my own code as well. Whenever sth changes, I currently manually read what changed in the changelog or compare files and then copy and paste everything into my own files. This is quite time consuming.
So now I was thinking about using a different approach:
Instead of long code snippets, only insert function calls and keep all of them in a separate file. Add this file to the make system.
If the source code changes, download it and re-insert all the changes automatically
Recompile, done
This way I can now compare old and new (untouched) versions with the original source code and see what has changed between the state of the code that I used and the new one.
My question is for step 2:
Line numbers might change if additional code is added. How can I find the right positions to inject my own functions?
Do as the Jonathan says. Use source control.
When you take your first look at an Oracle database, one of the first questions is often "where's the alert log?". Grid Control can tell you, but its often not available in the environment.
I posted some bash and Perl scripts to find and tail the alert log on my blog some time back, and I'm surprised to see that post still getting lots of hits.
The technique used is to lookup background_dump_dest from v$parameter. But I only tested this on Oracle Database 10g.
Is there a better approach than this? And does anyone know if this still works in 11g?
Am sure it will work in 11g, that parameter has been around for a long time.
Seems like the correct way to find it to me.
If the background_dump_dest parameter isn't set, the alert.log will be put in $ORACLE_HOME/RDBMS/trace
Once you've got the log open, I would consider using File::Tail or File::Tail::App to display it as it's being written, rather than sleeping and reading. File::Tail::App is particularly clever, because it will detect the file being rotated and switch, and will remember where you were up to between invocations of your program.
I'd also consider locking your cache file before using it. The race condition may not bother you, but having multiple people try to start your program at once could result in nasty fights over who gets to write to the cache file.
However both of these are nit-picks. My brief glance over your code doesn't reveal any glaring mistakes.