Commits

Michael Sperber committed f5b1de7

More updates to reflect the move to Bitbucket.

  • Participants
  • Parent commits 93eee47

Comments (0)

Files changed (2)

Develop/ChangeLog

+2012-01-03  Michael Sperber  <mike@xemacs.org>
+
+	* hgaccess.content: More updates to reflect the move to Bitbucket.
+
 2011-12-03  Vin Shelton  <acs@xemacs.org>
 
 	* hgaccess.content: The hg repositories have moved from debian to

Develop/hgaccess.content

 Steve Youngs &lt;youngs@xemacs.org&gt;
 Adrian Aichner &lt;adrian@xemacs.org&gt;
 Stephen J. Turnbull &lt;stephen@xemacs.org&gt;
+Vin Shelton &lt;acs@xemacs.org&gt;
+Mike Sperber &lt;mike@xemacs.org&gt;
 %main%
 
     <h1>XEmacs Mercurial Repository</h1>
       portable because it is entirely written in Python.  Binary
       packages are available for most platforms, either through native
       package distributions or from
-      <a href="http://www.selenic.com/mercurial/wiki/index.cgi/Download">
+      <a href="http://www.selenic.com/mercurial/wiki/Download">
 	Selenic</a>.</p>
 
     <p>
       clone the repository.</p>
 
     <pre xml:space="preserve">
-chibi$ <strong>hg clone http://hg.debian.org/hg/xemacs/xemacs xemacs-21.5</strong>
+chibi$ <strong>hg clone https://bitbucket.org/xemacs/xemacs-beta xemacs-21.5</strong>
 <i>(churn, churn, churn)</i>
     </pre>
 
 
     <p>
       If you have local changes that you'd like to keep under version
-      control, you can either use a separate repository or named
-      branches.  Here's one suggestion:</p>
-
-    <pre xml:space="preserve">
-Message-ID: &lt;87abmmc1lo.fsf@uwakimon.sk.tsukuba.ac.jp&gt;
-From: "Stephen J. Turnbull" &lt;stephen@xemacs.org&gt;
-Cc: XEmacs Beta List &lt;xemacs-beta@xemacs.org&gt;
-Subject: Converting from using CVS to hg
-Date: Thu, 31 Jan 2008 08:53:07 +0900
-
-robert writes:
-
- &gt; I have 21.5.b28 from CVS which I have kept uptodate.  I also have a few 
- &gt; changes to files in src and lisp for my own use.
- &gt; 
- &gt; I just got a clone of the current tree using
- &gt;   mv xemacs xemacs-cvs
- &gt;   hg clone http://hg.debian.org/hg/xemacs/xemacs
-
- &gt; When I want to update the xemacs tree, do I
- &gt;   cd xemacs
- &gt;   hg pull http://hg.debian.org/hg/xemacs/xemacs
-
-No, you should do "hg pull -u", which updates the directory from the
-default "other repository".  This starts out as the repo you cloned,
-and won't change unless you edit .hg/hgrc.  The update, like CVS,
-merges.
-
- &gt; If I am only compiling and using XEmacs--not contributing code, is
- &gt; hg still the way I should go?
-
-Yes.  Because hg is so much better at branching, what you probably
-want to do is to keep a pristine checkout of XEmacs, and a separate
-checkout of your changes.  so the initial clone would look like
-
-cd $parent
-hg clone http://hg.debian.org/hg/xemacs/xemacs
-mv xemacs xemacs-upstream
-hg clone xemacs-upstream
-for f in $files_I_want_to_keep_from_my_version; do
- cp f xemacs/$the_right_place
-done
-cd xemacs
-hg commit -m "Bring in my existing local changes."
-
-and your update process would look like:
-
-cd xemacs-upstream
-hg pull -u                # there should never be any merge conflicts
-cd ../xemacs
-hg pull -u
-# fix any merge conflicts here
-# if there were merge conflicts, commit
-
-Alternatively, you could use named branches.  Initial clone:
-
-cd $parent
-hg clone http://hg.debian.org/hg/xemacs/xemacs
-hg branch myxemacs
-for f in $files_I_want_to_keep_from_my_version; do
- cp f $the_right_place
-done
-hg commit -m "Bring in my existing local changes."
-
-and update
-
-cd xemacs
-hg checkout default
-hg pull                # no -u because you're just going to overwrite
-                       # again immediately
-hg checkout myxemacs
-hg merge default
-# fix any merge conflicts here
-hg commit -m "Merge $date."
-
-(WARNING: The above use of named branches is as yet untested by me!)
-    </pre>
-
-    <h3><a name="trusted-users">Do you have the paranoia blues?</a></h3>
-
-    <p>
-      Recent versions of Mercurial have had their security
-      consciousness strengthened.  Specifically, when another user has
-      committed an hgrc to the repository you're pulling from, you may
-      get a message that looks like
-    </p>
-
-    <pre xml:space="preserve">
-remote: not trusting file hg/xemacs/xemacs/.hg/hgrc from untrusted user sperber-guest, group xemacs
-    </pre>
-
-    <p>
-      In theory, Mike could cause execution of arbitrary code on your
-      box.  But hey, what's to worry: you're already running Dired and
-      EFS, aren't you?  Mike could have pwnzered you long ago, right?
-      So if you find that comforting, and you'd like to trust Mike,
-      run his workspace hgrc file in your xemacs workspace(s), and
-      incidentally suppress the warning, you can add
-    </p>
-
-    <pre xml:space="preserve">
-[trusted]
-users = sperber-guest
-    </pre>
-
-    <p>
-      to your ~/.hgrc <strong>on alioth.debian.org</strong>.  For more
-      information, see the Mercurial documentation.
-    </p>
+      control, you can either use a separate repository.
 
     <h3><a name="tags">Just how much do you want to bleed?</a></h3>
 
 	and update to the completely unfiltered repository that the
 	active developers are committing to:
 	<pre xml:space="preserve">
-chibi$ <strong>hg clone http://hg.debian.org/hg/xemacs/xemacs xemacs-21.5</strong>
+chibi$ <strong>hg clone https://bitbucket.org/xemacs/xemacs xemacs-21.5</strong>
 	</pre>
       </li>
       <li>
       repositories with any web browser.</p>
 
     <ul>
-      <li>The <a href="http://hg.debian.org/hg/xemacs/xemacs-beta">
+      <li>The <a href="https://bitbucket.org/xemacs/xemacs-beta">
 	  reviewed and approved beta versions</a></li>
-      <li>The <a href="http://hg.debian.org/hg/xemacs/xemacs">raw
+      <li>The <a href="https://bitbucket.org/xemacs/xemacs">raw
 	  patch stream</a></li>
     </ul>
 
 	  <tt>~/.ssh/id_rsa.pub</tt>.</p></li>
 
       <li>
-	If you are not already a Debian developer, you'll need to go
-	to <a href="http://alioth.debian.org/">Alioth</a>
-	(<code>http://alioth.debian.org/</code>) and get an account
-	for guest developers.  If you're not a Debian person, it will
-	have "-guest" appended to it, so be prepared.  (Sorry,
-	"unwelcome-guest" is already taken, but I can think of a few
-	others that are moderately creative.  Think!)</li>
+	If you do not already have a Bitbucket account, you'll need to go
+	to <a href="http://bitbucket.org/">the Bitbucket web site</a>
+	(<code>http://bitbucket.org/</code>) and get an account.
+	Register the ssh key you've just created with your account.</li>
 
       <li>
         Send the <a href="mailto:mike@xemacs.org">Mercurial
-	  Administrator</a> your Alioth user name and your public
-        ssh key (i.e. the contents of <tt>~/.ssh/identity.pub</tt> for
-        SSH 1, or <tt>~/.ssh/id_dsa.pub</tt> or
-        <tt>~/.ssh/id_rsa.pub</tt> for SSH 2).  The administrator
+	  Administrator</a> your Bitbucket.  The administrator
         will take care of the administrivia to give you
         access.</li>
 
 	  if necessary):</p>
 
 	<pre xml:space="preserve">
-Host hg.debian.org
-	User		<i>alioth-user</i>-guest
+Host bitbucket.org
+	User		<i>user</i>
 	ForwardX11	no
 	ForwardAgent	no
 	</pre>
       </li>
+
+      <li><p>Once your access is set up, you can pull from and push to
+      the repository via the alternate address:</p>
+	<pre xml:space="preserve">
+ssh://hg@bitbucket.org/xemacs/xemacs
+	</pre>
+      <p>If you've already checked out via HTTPS, you can redirect your
+	local repository to ssh access by editing the file
+	<code>.hg/hgrc</code>, which should contain a line:</p>
+	<pre xml:space="preserve">
+default = https://bitbucket.org/xemacs/xemacs
+	</pre>
+      <p>Change that line to:</p>
+	<pre xml:space="preserve">
+default = ssh://hg@bitbucket.org/xemacs/xemacs
+	</pre>
+
     </ol>
 
   <!-- Keep this comment at the end of the file