ToDo: Mercurial Repository

[JWPlatt]

CWE will be on a Mercurial repo. If you're new to Mercurial, I'll save you a little trouble.

See this nice little tutorial:
http://hginit.com/

Get TortoiseHg here:
http://tortoisehg.bitbucket.org/ (Bitbucket was acquired by Atlassian last year).

For Visual Studio fans, get VisualHg here:
http://visualhg.codeplex.com/

On the VisualHg page, there's this video tutorial link:
"To learn more about Mercurial, TortoiseHG and VisualHG watch Rob Conery's excellent video tutorial:"
http://tekpub.com/codeplex


For fans of both Visual Studeio and Subversion, I use TortoiseSvn and this very good integrated package (for purchase):
http://www.visualsvn.com/visualsvn/

[rarified]

[Distilled from a reply I just PMed to JW on an older PM thread.]

I've created the first foundry Hg repository for JW to experiment with. The backend infrastructure as far as linking Apache to Mercurial is finished, but the authentication is not. For now, access to any of the Mercurial repositories is restricted to registered users. I've taken the list of Subversion users (a'moaca', jwplatt, mac_fife, and rarified) and given them access through the Hg interface.

That gets you read access. The repository owner has to specify which users have "push" access by editing the <repo>/.hg/hgrc file and changing the "allow_push" list. This likely will change when I get Hg integrated with SSO access through Crowd.

The Hg web interface is at http://foundry.openuru.org/hg
The URL to directly access the test repository is http://foundry.openuru.org/hg/JW

I've confirmed that command line Mercurial as well as Windows-based TortoiseHg can access the repo using these URLs.

I'll let JW take it away with this repo. I'll let everyone know when I'm happy with access controls and ready to create the initial CWE repo.

_R

[JWPlatt]

Thanks!

I'm really looking forward to testing this!

Once tested, I want to make sure the chain of events always originate by the authority of Cyan Worlds. Cyan Worlds will be the CWE repo owner. They will assign the permissions and we will act under that authority. Practically speaking, it wouldn't matter in the end, but I'd rather do it properly. All we have to do is get Mark's attention.

[Mac_Fife]

Thanks rarified.

Speaking as a Mercurial noob: On the web interface, is it normal for the Find box at the top right to have no descriptive text around it other than the hover text (I'm in the office and using IE7, for what that's worth)?

[rarified]

I may need to bounce JIRA a few times tonight. Something is not right in the session transfer with Crowd, and I'm currently unable to log off JIRA.

Some would consider this a feature, but I hate unexplained mysteries

_R

[JWPlatt]

Speaking as a Mercurial noob: On the web interface, is it normal for the Find box at the top right to have no descriptive text around it other than the hover text (I'm in the office and using IE7, for what that's worth)?

Using IE8, I get the same, Mac. Looks normal.

I just tested a commit and push. It works fine and is browsable.

It would be nice if I could log off to test security...

[Mac_Fife]

OK. I guess I'm asking if it's intentional that there's no UI text to guide the user to what the box is for until he hovers on it. I'm not too fussed either way - I'd expect most prospective users to have enough "smarts" to figure it out pretty quickly, but it seems to go against the grain for UI design, so I just wondered if something was turning the text off.

[rarified]

Re: unlabeled search box.

As far as I know this is "normal". The web layout is completely dynamic, generated by the mercurial server python code, so it isn't a simple html change.

I expect, though that rather than steer people to the Hg interface directly, we'd send them through Fisheye to browse the source.

_R

[rarified]

Sorry for the delay on the Mercurial authentication.

A disadvantage to having a server that stays up for years with only occasional patching is that third-party software that comes from the vendor gets long in the tooth. Such is the case of the Solaris Foundry; the bundled Apache is 2.0.63, and that's too old to make use of any of the Atlassian connectors (which have to be built from source).

I'm going to create a new Apache server at 2.2.17, which will support the connectors. The build is done, I'm going to do some acceptance testing, and will have to take the portal down for a while to upgrade the config files and perhaps some of the htdocs/ structure.
The testing and conversion probably won't happen until tomorrow afternoon at the earliest.

What will this get us? Crowd (SSO) authentication to any particular subpath of the foundry URLs, fine-grained SVN access control. And a basis to create a Mercurial module with some access control as well, although Hg doesn't build in quite the same capabilities as SVN.

JW, if you feel comfortable enough with the static state of access control, I could create the CWE Hg repo and you could populate it now. It won't get out, it just will be a pain to change access until SSO is operational.

Bear with me, I'm peddlin as fast as I can

_R

[JWPlatt]

It can wait for the upgrade and testing. All the new work is really great of you to do, and I'd rather wait for a full path test in the final configuration without rushing you. I told you I allocated a month, and you've had, what, about four days so far?

No date has yet been targeted by Cyan, and they seem happy enough to wait until we say we're ready. So just keep the pace, take breaks when you need them, and don't burn out too young. You and Mac are both headed for a little time away in April. That's the only consideration I'm aware of at the moment.