Converting rdflib to mercurial?
Gunnar Aastrand Grimnes
We've discussed the option of converting rdflib to mercurial a few
times on #redfoot lately.
The benefits should be clear - easier to do
branching/merging/distributed development - easier for people
submitting patches, etc.
Google lets you switch and tells you how:
http://code.google.com/p/support/wiki/ConvertingSvnToHg
There are a few options when converting, keeping/discarding history,
branches, tags, etc.
I would propose converting and keeping history for:
/trunk and /tags
but wiping the slate clean for branches. Not that the old SVN repos
will not go away, it will just not be shown in the UI, and one can go
back and get at the branches etc. if you know the address.
Anything I've missed? Any good reasons NOT to switch? Clearly all
people developing will have to re-check-out (clone) their local
copies, but there doesn't seem to be that many people developing atm
:)
Any opinions? :)
- Gunnar
--
http://gromgull.net
Niklas Lindström
On Mon, Mar 21, 2011 at 3:21 PM, Gunnar Aastrand Grimnes
<grom...@gmail.com> wrote:
> Hi all,
>
> We've discussed the option of converting rdflib to mercurial a few
> times on #redfoot lately.
>
> The benefits should be clear - easier to do
> branching/merging/distributed development - easier for people
> submitting patches, etc.
+1 -- I'm all for it! (Was thinking of bringing it up again myself.)
> Google lets you switch and tells you how:
> http://code.google.com/p/support/wiki/ConvertingSvnToHg
>
> There are a few options when converting, keeping/discarding history,
> branches, tags, etc.
>
> I would propose converting and keeping history for:
>
> /trunk and /tags
I did it for Oort last year, and it went swell. (I even splitted the
repo into several, so I think skipping 'branches' should work out
well.)
> but wiping the slate clean for branches. Not that the old SVN repos
> will not go away, it will just not be shown in the UI, and one can go
> back and get at the branches etc. if you know the address.
>
> Anything I've missed? Any good reasons NOT to switch? Clearly all
> people developing will have to re-check-out (clone) their local
> copies, but there doesn't seem to be that many people developing atm
> :)
Can't think of anything critical. I'm sure doing this is all for the better.
Here's a checklist sketch for doing the conversion (to be used in
conjunction with the ConvertingSvnToHg article you referenced):
* I used a local svn mirror to speed up conversion (and in case
things fail), as recommended in one of the comments to the
ConvertingSvnToHg article (that comment links to
<https://gist.github.com/742668>, which I used as a blueprint).
* IIRC, "--filemap" is the key to exclude 'branches', 'wiki' and the others.
* Remember to convert and push the wiki as well.
* Verify that the new hg repo retains correct committer references
(I'm quite sure this is the case).
* Update the link in the description on PyPI (to
<http://rdflib.googlecode.com/hg/#egg=rdflib-dev>) so one can install
from latest head.
* Make sure other link references (to code etc.) are updated (in
README:s, from rdflib.net, etc.).
I believe that should cover the important things.
Best regards,
Niklas
Graham Higgins
Hash: SHA1
On 21 Mar 2011, at 14:21, Gunnar Aastrand Grimnes wrote:
> I would propose converting and keeping history for:
>
> /trunk and /tags
>
> but wiping the slate clean for branches.
That should help. Dan and I had a go at this a couple of years back. I
totally failed to persuade the conversion process to properly preserve
the repository's metastructure, so we let it ride for a while.
Simplifying the metastructure should ease the process considerably.
I have recently set up rdflib on github, if that's of interest:
https://github.com/gjhiggins/rdflib
and FWIW, taking note of Gunnar's observations on opportunities to run
tests, I set up Hudson CI build jobs for rdflib and for sundry under-
development rdfextras repositories:
http://bel-epa.com:8080/hudson/
My rdfextras repos is an over-enthusiastic restitution of all of the
modules and packages that were elided from rdflib3. The intended
exercise is one of discrimination between baby and bathwater, as well
as the picking-up of "unconsidered trifles" such as drewp's partial
implementation of a TokyoCabinet store and the AWOL "MySQLMassLoader"
contribution that was enquired after some time ago on rdflib-dev.
- - --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk2IvbIACgkQOsmLt1Nhivw54gCePd/ClPoA9MQl2y1qBlcp3TKR
TNMAoO9/AORGPBGRUgvTXJSvFDsKTZOJiQCVAgUBTYi9slnrWVZ7aXD1AQIS8gQA
hXzNcnAaPSkP3f5na0sEHB7lodLUkl0TlBwrRX8Gjh0ne0fTgYV+Sr6wXbJ4DKnT
6TQP9r0NcOsaeMTcsokV8reNMhJwBX5LfGk9sUTRgzMD+zs6YaRF1QJpw0NcyjCe
UfQzLzAuPoqMhkiHXH+HbD1wXTjE4boouh2L/t0DAZQ=
=xbZH
-----END PGP SIGNATURE-----
Graham Higgins
Hash: SHA1
On 21 Mar 2011, at 14:21, Gunnar Aastrand Grimnes wrote:
> I would propose converting and keeping history for:
>
> /trunk and /tags
>
> but wiping the slate clean for branches.
That should help. Dan and I had a go at this a couple of years back. I
totally failed to persuade the conversion process to properly preserve
the repository's metastructure, so we let it ride for a while.
Simplifying the metastructure should ease the process considerably.
I have recently set up rdflib on github, if that's of interest:
https://github.com/gjhiggins/rdflib
and FWIW, taking note of Gunnar's observations on opportunities to run
tests, I set up Hudson CI build jobs for rdflib and for sundry under-
development rdfextras repositories:
http://bel-epa.com:8080/hudson/
My rdfextras repos is an over-enthusiastic restitution of all of the
modules and packages that were elided from rdflib3. The intended
exercise is one of discrimination between baby and bathwater, as well
as the picking-up of "unconsidered trifles" such as drewp's partial
implementation of a TokyoCabinet store and the AWOL "MySQLMassLoader"
contribution that was enquired after some time ago on rdflib-dev.
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk2Is0AACgkQOsmLt1NhivxApwCgqlmmyxEqq+QmX0Rk7gfmHv/4
V9QAnAwsr1Rbz+FfdkZMSWXJYooVjqlkiQCVAgUBTYizQFnrWVZ7aXD1AQJUKwP6
AtJZxEEBnT/bziZ8T5EnbGAs2D0CwxYd5/1A5Ez7KfvROhZpjxDy7g2mxdnBU04x
Dv5MIe6EraGCFqXLvpLwj3ufpKELpti19LSDjd6SaeJnkb7HTgtoJ2hvz1gEnr04
8hYTSdBjNOq/102fMhMc3en+zV8t+9wEC6DNIMCcRgU=
=fBB2
-----END PGP SIGNATURE-----
Graham Higgins
Hash: SHA1
On 22 Mar 2011, at 15:18, Graham Higgins wrote, multiply:
> -----BEGIN PGP SIGNED MESSAGE-----
Sorry for the noise, Googlegroups' spam algo periodically has a "false
positive" relapse into the depths of googlemail.com/gmail.com despair,
taking me with it :-(
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk2Iz0EACgkQOsmLt1NhivyXMgCgxlF6Z6p8pOnILGo+EaA+9VVa
4/8AnjTQ8IjM25m1F3dpIhbNIuMpXYy2iQCVAgUBTYjPQVnrWVZ7aXD1AQKuywP+
MrYbOTJHCO1BnXZYfxiM3AbhwXWXZ/wEM21na/oQjsl+tzgcVQ89diTpk79yMOSL
zFrThXIRVFw16Oj6B4LxsTG2f+OCJjlKJo9fOHFZQ6jWqi6C4QhZTqiPdt3BT9az
QTgrggyHIn1qnXNQysP0vU6EAeDxuJT5iDukqkBsn3A=
=OwcO
-----END PGP SIGNATURE-----
Graham Higgins
Hash: SHA1
On 21 Mar 2011, at 14:21, Gunnar Aastrand Grimnes wrote:
> The benefits should be clear - easier to do
> branching/merging/distributed development - easier for people
> submitting patches, etc.
Before the submissions start flooding in :-)
Would this be an appropriate juncture at which to consider Will
Waites' suggestion w.r.t. introducing distribute and rejigging
plugin.py?
http://groups.google.com/group/rdflib-dev/msg/884a7876776188aa
(I felt a bit guilty even inadvertently sandwiching Will's post
between mine and was disappointed that it didn't spark any interest,
p'raps I should spoken up.)
On another tack...
I have an rdfextras repos on github which is a grab-bag of the
material migrated from rdflib and picked up elsewhere, to which I have
added the preliminaries of some documentation for rdfextras: Sphinx
documentation of the modules and tools plus some other related docs,
f'rinstance a blog post by Chimezie going into the details of the FOPL
Relation Model.
There's an HTML rendering here:
http://bel-epa.com/rdfextrasdocs/index.html
and the repos content is here:
https://github.com/gjhiggins/rdfextras/tree/master/rdfextras/docs
There's a significant amount of editing yet to be done.
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk2KzyMACgkQOsmLt1Nhivz7UQCgitavLZcAwARHM2BAFWW/Sn/c
bFQAoL1t+KmBoae0RHEitg47G4HUOGo9iQCVAgUBTYrPI1nrWVZ7aXD1AQJ60gQA
3uJs1i2W/wMmaRZfULLoltuKS6x1YRbntynyDth2cfc5fKsXVGKLxgC1wJnYrwi/
EqEZpoZ5kFEH3ERdMk4TfXREFaj2shtbWKPN4+NCppiFM1SBblIOA5+ZuryFhULN
/n4q/E+SI9fUL0K1Q3ISWuNQTRILMKpZZQCJUelelQQ=
=rf4S
-----END PGP SIGNATURE-----
Christoph Burgmer
Am Montag, 21. März 2011 schrieb Gunnar Aastrand Grimnes:
> We've discussed the option of converting rdflib to mercurial a few
> times on #redfoot lately.
...
> Any opinions? :)
we have rdflib on Git at https://github.com/nwebs/rdflib/tree/rdflib
As we work with Git and most Python packages we use are versioned with Git the
preferences here should be clear :)
-Chris
Gunnar Aastrand Grimnes
github, but I prefer mercurial :)
Also, I think hg/git cross-over plugins are meant to work quite well?
For Graham's point about working on plugin.py - I think this is a good
idea, but not really related to whether or not we change VCS?
Since no-one had any complaints - I will convert the google rdflib
repos some time this week - shout NOW if you disagree.
In particular, Eikeon : it's "your" project really - you do not mind mercurial?
Cheer,
- Gunnar
Graham Higgins
Hash: SHA1
On 29 Mar 2011, at 10:30, Gunnar Aastrand Grimnes wrote:
> In particular, Eikeon : it's "your" project really - you do not mind
> mercurial?
In case you don't get a reply: he doesn't mind mercurial in principle
- - we tried switching to mercurial a couple of years ago but couldn't
achieve a totally clean conversion w.r.t. branch histories:
http://groups.google.com/group/rdflib-dev/browse_frm/thread/033b5223f02a4209#
as branch histories won't be an issue this time (and that other
conversions to mercurial have been done by others), I have higher
hopes of success.
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk2RqZUACgkQOsmLt1NhivzDrACgu+yOFgIU10fGncrJbeqJDh7z
newAn19pnTYadeskvf/4VT+3D7IA3K7GiQCVAgUBTZGplVnrWVZ7aXD1AQJZ9AQA
0qyuEBgCCSG/ruDwviu37A+jK/rVQO/pIN/rylM5/5Eulcpf4/hWahRR2TlB4Ta4
/8daoy2IkLUVmFPXwZoBy8YHnuKC4j/ZVlOALtSFlzjP5RuoHk6oZ6RbvuCaazvN
KgqxhcG4oZyHxJErZD1cOCoLFBy92ChPyEVChOBBIDo=
=Y/5T
-----END PGP SIGNATURE-----
Gunnar Aastrand Grimnes
If you suddenly feel like committing - please hang on some minutes :)
- Gunnar
> --
> You received this message because you are subscribed to the Google Groups
> "rdflib-dev" group.
> To post to this group, send email to rdfli...@googlegroups.com.
> To unsubscribe from this group, send email to
> rdflib-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rdflib-dev?hl=en.
>
>
Niklas Lindström
Best regards,
Niklas
Gunnar Aastrand Grimnes
The new hg repository is now under:
https://rdflib.googlecode.com/hg/
Branches, and all other folders in trunk were not converted
(2005/2006/experimental_backends/rdflib_sparql)
They are still available from the old svn repository URL:
http://rdflib.googlecode.com/svn/
If anyone works on this code, they should restore it to a branch!
The wiki was also converted.
Anything else I/We need to do?
Cheers,
- Gunnar
2011/3/30 Niklas Lindström <linds...@gmail.com>:
Gunnar Aastrand Grimnes
Tags were converted - i.e. the tag we made for each release, they are
visisble in the UI or with "hg tags"
I see the VCS/Issue tracking integration of google code triggered
again for all commit messages that referenced a ticket - you may now
have lots of emails/rss entries that are old. Sorry about that!
- Gunnar
2011/3/30 Gunnar Aastrand Grimnes <grom...@gmail.com>:
Daniel Krech
Niklas Lindström
2011/3/30 Gunnar Aastrand Grimnes <grom...@gmail.com>:
> Done!
>
> The new hg repository is now under:
>
> https://rdflib.googlecode.com/hg/
Great work!
> The wiki was also converted.
Splendid!
> Anything else I/We need to do?
AFAIK, only:
* Update the link in the description on PyPI (to
<http://rdflib.googlecode.com/hg/#egg=rdflib-dev>) so one can install
from latest head.
* Make sure other link references (to code etc.) are updated (in
README:s, from rdflib.net, etc.).
Again, thanks a lot!
Best regards,
Niklas
Gunnar Aastrand Grimnes
>
> * Update the link in the description on PyPI (to
> <http://rdflib.googlecode.com/hg/#egg=rdflib-dev>) so one can install
> from latest head.
You mean the download URL for the package? Or just the link in the description?
Does easy_install support hg? I think pip does?
>
> * Make sure other link references (to code etc.) are updated (in
> README:s, from rdflib.net, etc.).
>
> Again, thanks a lot!
>
> Best regards,
> Niklas
>
Niklas Lindström
sorry for the late reply.
2011/3/30 Gunnar Aastrand Grimnes <grom...@gmail.com>:
>> AFAIK, only:
>>
>> * Update the link in the description on PyPI (to
>> <http://rdflib.googlecode.com/hg/#egg=rdflib-dev>) so one can install
>> from latest head.
>
> You mean the download URL for the package? Or just the link in the description?
I think the link in the description is the one to change to the format
described below (if at all).
> Does easy_install support hg? I think pip does?
I think they both do; but pip specifically seems to require embedded
repo references embedded in a PyPI page to be on the form
"hg+http://..." for mercurial repos (and similarly "git+http://..."
for git, etc.). It might be nice to have that on the RDFLib page so
one can do:
$ pip install rdflib==dev
for the latest stuff. Still, if one is ready to do that, one can
almost as easily do:
$ pip install -e hg+http://rdflib.googlecode.com/hg#egg=rdflib-dev
, so it might not be so big a deal.
Best regards,
Niklas