Start by running pendtest.bsp in Quoth, observe the pendulum slicing. Notice how you can collide with the flat of the blade without taking damage, but it slices into you when you stand in the path of the rotation.
There's a lot going on to make this one object work, so follow this guide while looking through the map files in an editor to get an idea of how it works.
The new idea (and the one that requires Quoth rather than plan Hipnotic) is to create the rotating entity as an external model, and then reference that model from the main map. This avoids the need to use an info_rotate entity (which historically made the rotating entity hard to texture and light correctly).
Take a look at the pendulum.map file first. You can see this just contains the brushes to make the physical, visible pendulum. Two things are important to note here
1) The brushes in this map are assigned to worldspawn, not part of an entity
2) The metal pivot at the top of the pendulum has been aligned exactly with the point '0 0 0' in the map. This point will be the centre of rotation for the object
Although I've been lazy in this test map and skipped lighting, another benefit of this file is that you can add lights to it. This lets you create lighting that looks reasonable at every angle the pendulum swings to.
The last thing to find out is how the external model is included after it's compiled. Open up pendtest.map in the editor. Normally, the brushes for a rotating object would be made into a "rotate_object" entity. In the case of an external model, we add a point entity to the main map with classname "rotate_object_point"; if you look at the example in pendtest, the key "model" "maps/pendulum.bsp" shows the format to specify the external model.
Each rotating object in hipnotic requires a collaboration between a visible "rotate_object" entity, and a second entity which controls that visible entity. In this case, we are using a using a "func_rotate_train" to control. The targetname field on the visible entity links to the target field on the controller. The other keys we set on the controler are the noise it makes, the obituary text, and the damage it inflicts - 10hp is probably a bit low for such a huge chopper, but it is a test map.
A rotating train needs a series of path entities which describe the sequence of rotations. For the back and forth rotation we want, only two "path_rotate" entities are needed. It's important to note that lots of different behaviours are possible at each step on the path, depending on the spawnflags used. In the example map the following are set: Angles & Stop rotate & Speed sets movetime
The first flag is the key to how our rotation works - we are stating that the waypoint specifies an angle for the object to face at the end of the movement (as opposed to setting a rate of rotation). "Speed sets movetime" is a bit of a convenience, it lets us say that the rotation must take 1 second directly, rather than having to calculate a speed of travel that makes the rotation look sensible. Stop rotate is cosmetic, it just adds a very short pause between each swing.
There's some subtlty to the angles chosen here: '410 0 0' and '-50 0 0'. The important thing to know is that after each step of the path completes, the angles of the object get normalised to the range 0-360. For example: after travelling to '-50 0 0', the angle is transformed to into '310 0 0', meaning that the object rotates forward to get to '410 0 0'. If we specified '50 0 0' instead of '410 0 0' the object would rotate the long way round, which is NOT what we want.
Finally, note that the path_rotate entities target each other to form a loop, while the "path" key of the func_rotate_train links it to the start of the path.
The movewalls are needed to give the blade collision. All of them are given the same targetname as the original rotate_object, so they are moved by the controller in the same way. For demonstration purposes I've applied the "visible" spawnflag and an alpha value of 0.5 so that you can see what they're doing in the demonstration map. This spawnflag is very helpful for debugging, but in a final release can be turned off again.
There's also an argument to be had over the "damage on touch" spawnflag. On the one hand, I like the fact that you can touch the flat of the pendulum without taking damage, but on the other hand, you only get pushed if you get hit by the edge of the blade but aren't trapped by the walls on the other side. Perhaps just setting this flag on the end movewalls would be a good compromise.