I use unison to sync a couple of directories between my laptop and desktop. Whenever there are new files on one system, I have to confirm each one individually:
<--- new file c [f]
I've scoured through the docs, but I can't seem to find a setting that will just auto-accept unison's recommendation. Is there one?
Yeah, the option -auto is what you're looking for. From the documentation:
auto
When set to true, this flag causes the user interface to skip asking for confirmations on non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)
Also of interest:
batch
When this is set to true, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.
Related
I've implemented a Dead Man Switch this way:
A script can be fired by an event. When the script starts it looks for a specific object on an S3 bucket. If that object can't be found for any reason (be it network issues to access the bucket, lack of permissions, the object was removed or any other reason) then the script will abort before doing any other actions.
I suppose this is a classic Dead Man Switch.
The idea is to let us remove this object in case we need to stop the script in an emergency.
My question is about terminology - I also supply a script to our team to create or remove that S3 object. I want it to be clear which actions means what (remove object - stop script from doing anything, create object - let the script continue with its work). I used "removed" and "reinstate" and was told this is too ambiguous. I now contemplate about "pushed" and "enabled" but this too sounds too vague. I'm also thinking about "pulled" (object removed) vs. "rearmed" (object created).
It's important that the terminology will be clear since if this script is used then this is expected to happen during emergency, so we want to minimize confusion as much as possible.
I suppose the problem is the inherent "double negative".
So far I didn't find any common name used to describe these actions. Wikipedia and other places describe what the switch is, but not actions of enabling or disabling it.
Any ideas?
I would say that the system would be:
Enabled if the object is present
Disabled if the object is absent
Placing the object would enable the script.
Removing (deleting) the object would disable the script.
You could even call the file enable-xxx-script to make it more obvious.
I am completely new using RTC so please, I need an answer as simple as possible.
I recently accepted a change set from another team member and I need to discard the change set from my workspace. My problem here is that the change set I accepted was not delivered and it's still pending and awaiting a review approval. If I discard the change set will this wipe out the team members changes or will it just remove the change set from my workspace? In other words, I am not going to remove any changes the other team member made am I?
I really need to understand this?
Thanks
If I discard the change set will this wipe out the team members changes or will it just remove the change set from my workspace?
Just from your workspace (and your repo workspace).
See help page "Discarding change sets from workspaces".
Once a change set is delivered to the stream, you cannot remove it.
And you will have to accept it eventually, especially if you want to deliver your own change sets yourself to that same stream.
If accepting that change set is problematic, then the developer who originally delivered that activity to the stream needs to revert it (deliver a new change set that would cancel the previous one).
See more at "How to discard the change set once delivered in RTC".
Erigami comments below:
You can remove a change set from a stream by:
discarding it from your workspace, then
running 'Replace in <stream name>' from the Pending Changes view.
That sets the component's history to be the same as that of your workspace, so make sure you have all of the change sets you want in there. ;)
I need to determinate which agents and daemons are disabled on my OSX. Each process has plist file with parameters. I assume "Disabled" key is responsible for that. But not all agents/daemons has this value. So if property list doesn't contain this paramater it means it's disabled or enabled? I didn't find any info regarding default value for this item.
Please provide a reference to apple's documentation which proof it.
The "Disabled" keys in each LaunchDaemon file can be overridden by an entry in /private/var/db/launchd.db/com.apple.launchd/overrides.plist, and there's a similar system for LaunchAgents in /private/var/db/launchd.db/com.apple.launchd.peruser.userID/overrides.plist. I don't think Apple has documented this anywhere, which means that you are not expected to interact directly with these files, just use launchctl. It also means they're subject to change (i.e. it didn't always work this way and might change without notice in a later version of OS X). Also, the file for LaunchDaemons is only readable by root.
This question is linked to :
Why can't all change sets be found when accepting change sets?
If RTC discovers that by accepting a change set some of the change sets which depend on this change set will not be accepted, is it possible to view what these change sets are ?
It seems very risky to accept a change set and not be 100% sure that the change sets being accepted contain same source code file changes as was intended by developer who delivered the change sets ?
What you can do is adding the repo workspace of the developer having delivered on the source stream.
You would add that repo workspace as a flow target of your own repo workspace (the one you are using for the merge)
By setting that new flow target as current, you can quickly see what change set you are missing.
Of course, the real issue is that what I just proposed doesn't scale: if you have multiple developers having made partial delivers (with missing intermediate change sets), then you would need to have a look in turn to each developer's repo workspaces.
That is why you have since 2007(!) the "blocker" Work Item "Enhancement 24822":
"Confirm Content Accept" dialog should be more specific (offer to fill in gaps when a gap exception occurs)
... but it is still unresolved, even in the latest RTC4.x.
I am trying to setup some group maintained folders that should not be seen by the other groups. Currently, I achieve that by un-clicking the "Inherit permissions from higher levels" check-box in the ##sharing tab, but I would like to automate this.
I could not find anything about this in the documentation or googling. After searching around the eggs directory I found some interesting things about 'ac_inherited_permissions' but nothing jumped out at me as my solution.
I'd like to do something like obj.inherited_permissions = False, or call whichever function I need to.
Any ideas?
The sharing tab only affects local roles. These usually are inherited from parents (acquired), but you can explicitly block these by setting __ac_local_roles_block__ to True on an object.
Make sure, however, you set this on the unwrapped object (no acquisition context):
from Acquisition import aq_base
aq_base(object).__ac_local_roles_block__ = True