<div dir="ltr">Accidentally hit Reply instead of Reply-to-all.<div><br></div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Erik Huelsmann</b> <span dir="ltr"><<a href="mailto:ehuels@gmail.com">ehuels@gmail.com</a>></span><br>Date: Mon, Mar 9, 2015 at 9:08 PM<br>Subject: Re: [Clo-devel] Testing GitLab installation & migration nearing completion: steps to cut-over<br>To: Raymond Toy <<a href="mailto:toy.raymond@gmail.com">toy.raymond@gmail.com</a>><br><br><br><div dir="ltr">Hi Raymond,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Mar 9, 2015 at 4:41 PM, Raymond Toy <span dir="ltr"><<a href="mailto:toy.raymond@gmail.com" target="_blank">toy.raymond@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>>>> "Erik" == Erik Huelsmann <<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>> writes:<br>
<br>
[snip]<br>
<br>
    Erik> Another important thing to note is that repositories having<br>
    Erik> been brought under GitLab control, will no longer be<br>
    Erik> available on their old locations. For gitweb, there will be<br>
    Erik> redirect rules instated, as will there be for direct<br>
    Erik> repository access over https.<br>
<br>
Does that mean any repos using hg will get converted too and not be<br>
available from their old locations?</blockquote><div><br></div></span><div>No: they'll stay right where they currently are. I've thought about offering migration to GitLab, but there's relatively little for <a href="http://common-lisp.net" target="_blank">common-lisp.net</a> to win (I think): we don't support (and won't in the future) repository browsing with any tools (right?). So, all that we'd win is to be able to delete the 'hg' binary from the system. Well, that's too little gain for the pain.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What does this mean for the Trac "Browse Source" button?  Will these get updated appropriately?<br></blockquote><div><br></div></span><div>Hmm. I don't know how to do that, really. Basically, the plan as it's laid out now, assumes that all git projects move their source browsing over to gitlab. CMUCL uses a non-common-lisp.net-standard configuration for Trac. I don't really know how many projects currently do the same. I'll need to look into that. Basically, my solution would be to redirect all "browse", "tickets" and "wiki" urls to the gitlab namespace for those projects that used Trac to go with Git/Darcs.</div><span class=""><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not that it matters all that much. I do plan on converting my one and<br>
only hg repo to git, if it's not done for me as part of the migration.<br></blockquote></span></div><div><br></div><div>It's planned, but not for this migration. You're absolutely welcome to do it yourself as soon as the system is opened for general access. May I ask that you mark the Mercurial repository in some recognizable way that it should not be migrated, or better yet, that you make a local copy for yourself and remove the repository from the <a href="http://common-lisp.net" target="_blank">common-lisp.net</a> system, so it doesn't get migrated twice?</div><div><br></div><div>Thanks!</div><span class=""><div><br></div>-- <br><div><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</span></div></div>
</div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div></div>