Note that there are some explanatory texts on larger screens.

plurals
  1. POVerifying Mercurial Changesets are from who they say they're from
    primarykey
    data
    text
    <p>I'm investigating using Mercurial in a corporate environment. The plan is to use central repositories hosted by a webserver (IIS) which developers will push to once they've tested changes locally or within their teams.</p> <p>I have IIS configured to authenticate users against Active Directory, but there seems to be a hole in that while I can enforce who can push, I can't enforce that they sign their changesets as themselves.</p> <p>For example, given a basic "commit" scenario:</p> <ol> <li>user commits to their local repository</li> <li>user pushes their changes to the central repository</li> </ol> <p>In step 1, the user provides a username (via their .hgrc file or whatever) to their local repository, but there isn't really any way to enforce that this is their "real" username.</p> <p>In step 2, the user has to provide their "real" credentials to IIS to be allowed to push, but their changesets will show up in the history with whatever username they provided in step 1. It seems like if bob used "alice" as his username for step 1, he could make sure alice got the blame for any of his buggy changes.</p> <p>Is there a way to make sure these user names match up during the push (via hooks or something)? Or alternatively, some other way to ensure a reasonable level of authenticity in the change long?</p> <p><strong>Edit:</strong> On further consideration, I guess I don't actually want to enforce that these names line up; if Bob and Alice have been collaborating in a separate repo, Bob should ultimately be able to push all of their changes, not just his own. What I really want is just to make sure that if it comes down to it, I can tell who made what changes in a more definitive way than just whatever username was applied.</p> <p>I'm thinking <a href="http://mercurial.selenic.com/wiki/GpgExtension" rel="nofollow noreferrer">GpgExtension</a> is part of the answer, but I still don't think I've got the full picture.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload