Keep a record of who pushed revisions to a repository

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/8/2011 8:34 AM, Krzysztof Nowicki wrote:
> Hi,
> 
> I know about the signatures. I was thinking about using them but I didn't want
> to take out such a big gun as it would require all users to setup GPG (we're
> talking Windows users here :( ). All I really need is some sort of metadata to
> indicate the real committer. I don't need NSA-level security here.
> 
> I wonder however if it would be possible to utilize the storage used for
> signatures to store a short metadata indicating the real committer. This would
> need to be done by a hook on the smart server. I'll try to play with it.
> 
> Thanks anyway
> 
> Krzysztof
> 

With a distributed setup, the person who pushed the changes is not
necessarily the one that committed them.

If you prototype some work, I merge it into my branch and finish it off,
and then we push it to the trunk, all of those revisions get pushed by
one person, even though there are revisions from multiple people involved.

I could see using a server-side hook to store out-of-band (in a separate
file from the bzr data itself) what revisions were pushed to what branch
by what authenticated user.

I'm not fully sure what you gain by this, though. If it is about knowing
who landed the final change on trunk, you could set
"append_revisions_only = True" in branch.conf, and have a general policy
that people use a checkout of trunk to merge in changes and commit
there. Rather than just pushing to trunk. (Append_revisions_only
prevents them from merging trunk into their branch and pushing to trunk.
They have to preserve the mainline history from trunk to push to trunk.)


I think what you are asking for is going to be pretty custom for your
installation. Mostly because bzr currently avoids tracking Auth info,
rather than duplicating the work of stuff like SSH.

Certainly I could see using a patch in StreamSink so that whenever you
see a new revision, you log the current username. There will be ways
around it, of varying complexity. So it depends how hard you want to
push on it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk114m8ACgkQJdeBCYSNAAOnPwCgzFcQH8a8VCEs81BO7ldyxEm5
lPAAnRZW/1vaa04u+E1z2uaqB9dpuMLO
=kNUf
-----END PGP SIGNATURE-----