pure-lang repository migrated to Mercurial
Albert Graef
as you probably noticed, I switched the repository to Mercurial today. :)
Everything should be up and running again. I also fixed the wiki links
and the installation instructions accordingly. Please let me know if you
still find dangling links or other inconsistencies anywhere.
You'll find the new repos at:
source (aka default): http://code.google.com/p/pure-lang/source/browse/
wiki: http://code.google.com/p/pure-lang/source/browse?repo=wiki
(The old svn repo is still there, but should be considered "closed", so
please don't commit to it any more. You can check it out as before with
'svn co http://pure-lang.googlecode.com/svn pure-lang' if you need to
grab old revisions or look at the log.)
As usual, see the http://code.google.com/p/pure-lang/source/checkout for
checkout instructions (you'll need to have Mercurial installed to do
that, of course).
If you know svn, using mercurial is dead-easy, you just have to remember
that all your updates and commits are local and that you need to
occasionally 'pull' or 'push' updates between your clone and the central
repo at GC.
Here are the most important commands:
- 'hg clone https://pure-lang.googlecode.com/hg pure-lang' gives you a
clone of the source repo in directory 'pure-lang', which you also use as
your working copy.
- 'hg pull' followed by 'hg up' (or simply 'hg pull -u') updates your
clone and the working copy to the latest revision from the server. You
can also run 'hg in' beforehand to see what changes would be pulled.
- You can change files as usual and commit them locally with 'hg ci'.
When you feel like updating the central repo, use 'hg out' to see what
local changes you are about to send, then 'hg push' to actually push
them to the central repo.
- Other useful commands familiar from svn are 'hg status', 'hg log' and
'hg diff'. Also try 'hg help' for hg's builtin help.
If you plan to commit stuff, it's a good idea to set up your ~/.hgrc
with your username like this:
# This is a Mercurial configuration file.
[ui]
username = My Name <email>
Also, as a project member you may want to add an authentication section
like this if you don't want to retype your username and password when
you do a 'hg push':
[auth]
pure_lang.prefix = https://pure-lang.googlecode.com/
pure_lang.username = <your googlecode id>
pure_lang.password = <your googlecode commit password>
Of course, don't make ~/.hgrc world-readable when you do this. ;-)
That should be all that's needed for basic usage, but of course there's
much more. The O'Reilly book about Mercurial can be read online here:
http://hgbook.red-bean.com/
Enjoy. :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Ryan Schmidt
> as you probably noticed, I switched the repository to Mercurial today. :)
Am I correct in realizing that there isn't a way to get only part of the repository?
To build the latest version of pure from Subversion, I might get the source code this way:
svn co http://pure-lang.googlecode.com/svn/trunk/pure@3737
This gets only pure (not the other projects) and only trunk (not the branches or tags).
Is there an hg equivalent for that, or must I now get the entire repository?
Albert Graef
> Am I correct in realizing that there isn't a way to get only part of the repository?
That's right, unfortunately. I decided that it would be more convenient
to have everything in one big repo, so that it's easy to get the whole
shebang and move stuff around between subprojects. I realize now that
this is not ideal for port and package maintainers, though. :(
Note that this is basically the same with all DVCS. Mercurial, like Git,
has some kind of subrepo support [1], so that you can get some of the
benefits of a big repository while maintaining separate repositories for
the subprojects. But this looks rather complicated, so I don't think I
want to do it that way.
[1] http://mercurial.selenic.com/wiki/Subrepositories?action=show.
Maybe you could use Roman's snapshots at
http://codex.sigpipe.cz/pure-lang/snapshots/balls/ instead?
Roman hasn't updated this for the new Hg repository yet, however. Also,
I guess that you'd need a 'latest' link for each package. Roman, would
that be possible?
Ryan Schmidt
On Oct 31, 2010, at 00:13, Albert Graef wrote:
> Ryan Schmidt wrote:
>> Am I correct in realizing that there isn't a way to get only part of the repository?
>
> That's right, unfortunately. I decided that it would be more convenient
> to have everything in one big repo, so that it's easy to get the whole
> shebang and move stuff around between subprojects. I realize now that
> this is not ideal for port and package maintainers, though. :(
Ok, just making sure I wasn't missing something. I'll have it fetch the whole repo then, which is only 18 MB right now which is not very big compared to some other ports. Plus, hardly anybody will be using the development version port, since I haven't been updating it much other than simultaneously with the stable version port.
Roman Neuhauser
> Hi everyone,
>
> as you probably noticed, I switched the repository to Mercurial today. :)
> that all your updates and commits are local and that you need to
> occasionally 'pull' or 'push' updates between your clone and the central
> repo at GC.
- color: outpuf from various hg subcommands colored according to
builtin or user-specified rules
- crecord: choose changes to commit with granularity down to single
line
- graphlog: eases navigation in the non-linear history of a hg
repository
- histedit: amend, shuffle, fold, drop changesets
- mq: publishes the strip subcommand which allows you to get rid of
trailing (ranges of) changesets
- parentrevspec: specify revisions using git-style suffixes
- purge: eases getting rid of unknown files
- rebase: facilitates moving trailing (ranges of) changesets between
different parts of the DAG
- record: not as cool as crecord, but works on windows
most of those are bundled with mercurial but not enabled by default.
the rest is easy to find (http://mercurial.selenic.com/wiki/
UsingExtensions)
Albert Graef
> here's a few extensions i consider essential:
Extensions are a piece of cake. ;-) Thanks for the list, I enabled these
now (as well as bookmarks, convert, fetch, info and hgsubversion).
Roman Neuhauser
> Roman Neuhauser wrote:
> > here's a few extensions i consider essential:
>
> Extensions are a piece of cake. ;-) Thanks for the list, I enabled these
> now (as well as bookmarks, convert, fetch, info and hgsubversion).
hgsubversion... git's subversion support is way better. faster, more
reliable.
while i'm at it:
if you use rebase, make sure to use --detach. rebase has this
annoying habit of turning the (first) moved changeset into a
"merge" (it will have two parents) if it decides that the source and
destination are unrelated (one is not an ancestor of the other).
similarly, if the rebase is nontrivial, use --keep. rebase has
another annoying habit: it'll drop dead half way through the repo
modification leaving you without the old revisions or a way to fix the
situation. you can get rid of the old revisions with strip.
also, i recommend using the git diff format. it's not default because
of compatibility concerns, but is way more useful for day-to-day work:
it clearly shows copy/move operations and permission changes. see
hgrc(5).
--
roman
Albert Graef
> if you use rebase, make sure to use --detach. rebase has this
> annoying habit of turning the (first) moved changeset into a
> "merge" (it will have two parents) if it decides that the source and
> destination are unrelated (one is not an ancestor of the other).
> similarly, if the rebase is nontrivial, use --keep. rebase has
> another annoying habit: it'll drop dead half way through the repo
> modification leaving you without the old revisions or a way to fix the
> situation. you can get rid of the old revisions with strip.
I should add that, as with git, 'rebase' is your friend when the central
repo has moved forward while you have been working on your own things.
Without 'rebase', you'll have to pull, then merge and commit, before you
can push your changes. This creates a branching point in the repo. For
most kinds of local changes this is really unnecessary. Instead, you do
a 'hg pull --rebase' which works like 'hg pull --update' but also
rebases your local revisions on the repo head, thereby maintaining a
linear history. If you then push your changes, they appear as if you had
based them on the head of the repo in the first place.
The 'rebase' extension comes bundled with Mercurial, so all you have to
do is enable it in your .hgrc file:
[extensions]
rebase =
I'd really like to recommend that everyone committing to the pure-lang
repo enable this, and have a look at the description of the rebase
extension which is available here:
http://mercurial.selenic.com/wiki/RebaseExtension
Also, the following page shows some use cases:
http://mercurial.selenic.com/wiki/RebaseProject
If you're new to hg and you can't make any sense of the above
descriptions, then you should probably first review how branches work in
hg. There's a nice tutorial by Steve Losh about that here:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
And of course there are the relevant sections in the Definitive Guide:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html
I wonder why the Definitive Guide doesn't even mention 'rebase'. I
consider it essential.
HTH,
Neuhauser, Roman (GE Capital, consultant)
> Roman Neuhauser wrote:
> > if you use rebase, make sure to use --detach. rebase has this
> > annoying habit of turning the (first) moved changeset into a
> > "merge" (it will have two parents) if it decides that the source and
> > destination are unrelated (one is not an ancestor of the other).
> > similarly, if the rebase is nontrivial, use --keep. rebase has
> > another annoying habit: it'll drop dead half way through the repo
> > modification leaving you without the old revisions or a way to fix the
> > situation. you can get rid of the old revisions with strip.
>
> I should add that, as with git, 'rebase' is your friend when the central
> repo has moved forward while you have been working on your own things.
>
> Without 'rebase', you'll have to pull, then merge and commit, before you
> can push your changes. This creates a branching point in the repo. For
> most kinds of local changes this is really unnecessary. Instead, you do
> a 'hg pull --rebase' which works like 'hg pull --update' but also
> rebases your local revisions on the repo head
i must warn against using hg up --rebase, see rebase's annoying habits described above. hg rebase is cool as long as you use it with --keep and strip the source changesets with hg strip afterwards.
> And of course there are the relevant sections in the Definitive Guide:
>
> http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
> http://hgbook.red-bean.com/read/managing-releases-and-branchy-
> development.html
>
> I wonder why the Definitive Guide doesn't even mention 'rebase'. I
> consider it essential.
http://www.selenic.com/blog/?p=681:
Revitalizing the book - we also discussed updating the Mercurial book to be more current. This probably means turning it into an active community-based project. We kicked around ideas a wishlist of ideas for improving the book, and have just begun discussing this again on the mailing list..
Albert Graef
> i must warn against using hg up --rebase, see rebase's annoying habits described above. hg rebase is cool as long as you use it with --keep and strip the source changesets with hg strip afterwards.
Ok, so which sequence of commands would you actually use in that
situation? Be gentle, we're all still learning hg here I guess. ;-) I
haven't come across the problems you mention yet, neither have I seen a
hg tutorial which describes hg rebase in any depth. So a quick intro for
dummies would be really appreciated!
Neuhauser, Roman (GE Capital, consultant)
> Neuhauser, Roman (GE Capital, consultant) wrote:
> > i must warn against using hg up --rebase, see rebase's
> > annoying habits described above. hg rebase is cool as long
> > as you use it with --keep and strip the source changesets
> > with hg strip afterwards.
>
> Ok, so which sequence of commands would you actually use in that
> situation? Be gentle, we're all still learning hg here I guess. ;-) I
> haven't come across the problems you mention yet, neither have I seen a
> hg tutorial which describes hg rebase in any depth. So a quick intro for
> dummies would be really appreciated!
hg in # shows incoming changesets, i'll want to rebase my stuff with:
hg ou -l1 # i note the hash of the first changeset
hg pull
hg reb --keep --detach -d tip -s $hash
# if anything broke, i can fix it up and continue with
hg reb --cont
# when everything's ok, then
hg str $hash
this works the same no matter how many topological branches extra compared to the master i have. if i have more than one, i simply repeat this procedure until they're all "linearized".
the procedure could be a little simplified if i used hg heads instead of hg ou -l1 and hg reb -b $myhead instead of hg reb -s $firstdivergent, but i grew a bit weary of hg reb's surprises, and stay on the safe side.
--
roman
Albert Graef
> hg in # shows incoming changesets, i'll want to rebase my stuff with:
That's a mouthful. :) Guess I'll have to look it up again when I do it
next time, or write myself a little shell function to help with it. But
I just tried it and it works great, many thanks!
Roman Neuhauser
> Neuhauser, Roman (GE Capital, consultant) wrote:
>
> > hg in # shows incoming changesets, i'll want to rebase my stuff with:
>
> That's a mouthful. :)
have a two-pronged fork and stand on your own head (iow not the one
you've just pulled in), simple `hg reb` will do. also, i'm quite
probably guilty of basing my judgements of current hg on outdated
experiences.
--
roman