Getting Adium onto Github

[Amelia Rose Khan]

Hello all,

Would be nice to see that Adium be placed here: https://github.com/adium which
would allow others to work with the code easier.

Thanks,
Amelia Rose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/2772279d/attachment.html>

[Christopher Forsythe]

How would it make it easier for others to work on the code?

Post by Amelia Rose Khan
Hello all,
Would be nice to see that Adium be placed here: https://github.com/adium which
would allow others to work with the code easier.
Thanks,
Amelia Rose

[Bob Tanner]

Post by Christopher Forsythe
How would it make it easier for others to work on the code?

This isn't meant to be a +1 for GitHub, but Xcode's native support for git. As I do must of my dev work with bzr and launchpad I get questioned about why not GitHub a lot and the major reason people push for GitHub is the native support inside of Xcode.

--
Bob Tanner <tanner at real-time.com> | Phone : [phone]
http://www.real-time.com, Linux, OSX, VMware | Fax : [phone]
Key fingerprint = 9906 320A 8BB6 64AD 96A7 7785 CBFB 10BF 568B F98C

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/ddd0572f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/ddd0572f/attachment-0001.bin>

[Jon Chambers]

I'm not asserting that other systems don't have helpful features, but
I think Github's pull requests are a really nice tool. They make it
easy for outside developers to submit patches and do a really nice job
of facilitating conversations about code changes.

I recognize that changing version control systems and service
providers and workflows are all Really Big Deals in their own right,
and doing all of those at once is an Even Bigger Deal, but I (as an
outside developer) do think it's a thing worth considering.

-Jon

Post by Christopher Forsythe
How would it make it easier for others to work on the code?
This isn't meant to be a +1 for GitHub, but Xcode's native support for git.
As I do must of my dev work with bzr and launchpad I get questioned about
why not GitHub a lot and the major reason people push for GitHub is the
native support inside of Xcode.
--
Bob Tanner <tanner at real-time.com> | Phone : [phone]
http://www.real-time.com, Linux, OSX, VMware | Fax : [phone]
Key fingerprint = 9906 320A 8BB6 64AD 96A7 7785 CBFB 10BF 568B F98C

[Thijs Alkemade]

Post by Jon Chambers
I'm not asserting that other systems don't have helpful features, but
I think Github's pull requests are a really nice tool. They make it
easy for outside developers to submit patches and do a really nice job
of facilitating conversations about code changes.
I recognize that changing version control systems and service
providers and workflows are all Really Big Deals in their own right,
and doing all of those at once is an Even Bigger Deal, but I (as an
outside developer) do think it's a thing worth considering.
-Jon

We have an automatically synchronized Bitbucket mirror. Why do you prefer
Github's pull requests over Bitbucket's?

I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried those
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull request to
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/987e936c/attachment.bin>

[Colin Barrett]

Post by Thijs Alkemade
I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried those
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull request to
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.

Some things:

- Github has a soft repo limit of 1GB. A bunch of forks of a 2.5GB Adium would probably not make them happy (https://help.github.com/articles/what-is-my-disk-quota)

- As part of trying to fix our external binary files problem, we could put the binary files in an external repo, hosted by us, and write a script to download the correct versions after checkout. (The script would be versioned, which would keep old versions of the source available. And if the directory where library verisons were downloaded to was marked as ignored by Git, it could function as a local cache making offline usage less painful.) (I also have ideas about some simple pre-processor things we can do to make the "check out adium, try to build" workflow at least have a helpful error message.)

- The above would mean starting over, again, on a new repository. Frustrating because now we've got history in even more places.

- I worry about the GPL nature of Adium being unclear to contributors and Github's pull requests, while easy to use, make it very, very difficult to confirm that a contributor is aware of the licensing situation.

Would it be worth it? I don't really know. But attracting new contributors to Adium is certainly important, especially at the moment.

Let me know if there's anything I can do to help.

-Colin

[Peter Hosey]

Post by Colin Barrett
- As part of trying to fix our external binary files problem, we could put the binary files in an external repo, hosted by us, and write a script to download the correct versions after checkout.

Or use submodules.

[Colin Barrett]

Post by Peter Hosey

Post by Colin Barrett
- As part of trying to fix our external binary files problem, we could put the binary files in an external repo, hosted by us, and write a script to download the correct versions after checkout.

Or use submodules.

My understanding of both submodule and subtree is that they actually do a full checkout. Which wouldn't save any download time or disk-space.

-Colin

[Thijs Alkemade]

Post by Colin Barrett

Post by Thijs Alkemade
I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried those
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull request to
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.

- Github has a soft repo limit of 1GB. A bunch of forks of a 2.5GB Adium would probably not make them happy (https://help.github.com/articles/what-is-my-disk-quota)
- As part of trying to fix our external binary files problem, we could put the binary files in an external repo, hosted by us, and write a script to download the correct versions after checkout. (The script would be versioned, which would keep old versions of the source available. And if the directory where library verisons were downloaded to was marked as ignored by Git, it could function as a local cache making offline usage less painful.) (I also have ideas about some simple pre-processor things we can do to make the "check out adium, try to build" workflow at least have a helpful error message.)

This sounds exactly like re-inventing the largefiles extension for hg. ;)

The downside is that we would need to rebuild our repository to include
support for it, otherwise we don't benefit.

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130213/396cd5d0/attachment.bin>

[Jon Chambers]

Post by Colin Barrett
I worry about the GPL nature of Adium being unclear to contributors and Github's pull requests, while easy to use, make it very, very difficult to confirm that a contributor is aware of the licensing situation.

I don't quite understand the problem here (which isn't to say there
isn't one!); couldn't you just post a comment on the request saying
"please confirm that you understand the licensing situation before we
merge this?" It seems like that would neatly bundle the patch with a
statement from the author.

-Jon

On Tue, Feb 12, 2013 at 6:13 PM, Colin Barrett

Post by Colin Barrett

Post by Thijs Alkemade
I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried those
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull request to
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.

- Github has a soft repo limit of 1GB. A bunch of forks of a 2.5GB Adium would probably not make them happy (https://help.github.com/articles/what-is-my-disk-quota)
- As part of trying to fix our external binary files problem, we could put the binary files in an external repo, hosted by us, and write a script to download the correct versions after checkout. (The script would be versioned, which would keep old versions of the source available. And if the directory where library verisons were downloaded to was marked as ignored by Git, it could function as a local cache making offline usage less painful.) (I also have ideas about some simple pre-processor things we can do to make the "check out adium, try to build" workflow at least have a helpful error message.)
- The above would mean starting over, again, on a new repository. Frustrating because now we've got history in even more places.
- I worry about the GPL nature of Adium being unclear to contributors and Github's pull requests, while easy to use, make it very, very difficult to confirm that a contributor is aware of the licensing situation.
Would it be worth it? I don't really know. But attracting new contributors to Adium is certainly important, especially at the moment.
Let me know if there's anything I can do to help.
-Colin

[Thijs Alkemade]

Post by Thijs Alkemade

Post by Jon Chambers
I'm not asserting that other systems don't have helpful features, but
I think Github's pull requests are a really nice tool. They make it
easy for outside developers to submit patches and do a really nice job
of facilitating conversations about code changes.
I recognize that changing version control systems and service
providers and workflows are all Really Big Deals in their own right,
and doing all of those at once is an Even Bigger Deal, but I (as an
outside developer) do think it's a thing worth considering.
-Jon

We have an automatically synchronized Bitbucket mirror. Why do you prefer
Github's pull requests over Bitbucket's?
I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried those
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull request to
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.
Thijs

Okay, I took a closer look.

* In the repository that ran the conversion, the .hg/git directory is 909MB.
This is a fresh conversion, but might have included a couple of local
commits I never pushed.
It was a fresh conversion, as after I tried `git gc`, hg-git was unable to
push to github. I guess it accidentally deleted something git considers
garbage but hg-git doesn't.
* https://github.com/settings/repositories shows it as:
xnyhps/adium 2681.82MB
* Cloning that resulted in a 648 MB directory (so working directory
and .git).
* `git gc --aggressive` brought that down to 386 MB.

I don't really know what's going on with the size Github shows. I'd guess
they run `git gc` at least once in a while. I'll try deleting the
repository, and pushing a clone that was gc'ed locally first instead.

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130213/e65f114c/attachment.bin>

[Graham Booker]

Post by Thijs Alkemade

Post by Thijs Alkemade

Post by Jon Chambers
I'm not asserting that other systems don't have helpful features, but
I think Github's pull requests are a really nice tool. They make it
easy for outside developers to submit patches and do a really nice job
of facilitating conversations about code changes.
I recognize that changing version control systems and service
providers and workflows are all Really Big Deals in their own right,
and doing all of those at once is an Even Bigger Deal, but I (as an
outside developer) do think it's a thing worth considering.
-Jon

We have an automatically synchronized Bitbucket mirror. Why do you prefer
Github's pull requests over Bitbucket's?
I'm not against also running a Github mirror, there are tools that should
allow lossless conversion between the two. However, last time I tried

those

Post by Thijs Alkemade
(https://github.com/xnyhps/adium), the repository went from ~700 MB to
2.5GB. Anyone who would want to use Github to quickly send a pull

request to

Post by Thijs Alkemade
Adium would probably give up trying to clone that. I could have a look at
what causes that enormous increase in size, but unless we decide to drop
a lot of history and create a new repository without binary frameworks it
will still end up quite large.
Thijs

Okay, I took a closer look.
* In the repository that ran the conversion, the .hg/git directory is 909MB.
This is a fresh conversion, but might have included a couple of local
commits I never pushed.
It was a fresh conversion, as after I tried `git gc`, hg-git was unable to
push to github. I guess it accidentally deleted something git considers
garbage but hg-git doesn't.
xnyhps/adium 2681.82MB
* Cloning that resulted in a 648 MB directory (so working directory
and .git).
* `git gc --aggressive` brought that down to 386 MB.
I don't really know what's going on with the size Github shows. I'd guess
they run `git gc` at least once in a while. I'll try deleting the
repository, and pushing a clone that was gc'ed locally first instead.

You may want to run the repack with the appropriate options instead of gc
--aggressive:
http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/

Since this is a one-time operation, you should run the repack with the -f.
I've played with this on repositories converted from SVN, and I found that
repack tends to do better than gc --aggressive in terms of repository size.

Post by Thijs Alkemade
Thijs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/24bf375a/attachment-0001.html>

[Thijs Alkemade]

Post by Graham Booker

Post by Thijs Alkemade
Okay, I took a closer look.
* In the repository that ran the conversion, the .hg/git directory is 909MB.
This is a fresh conversion, but might have included a couple of local
commits I never pushed.
It was a fresh conversion, as after I tried `git gc`, hg-git was unable to
push to github. I guess it accidentally deleted something git considers
garbage but hg-git doesn't.
xnyhps/adium 2681.82MB
* Cloning that resulted in a 648 MB directory (so working directory
and .git).
* `git gc --aggressive` brought that down to 386 MB.
I don't really know what's going on with the size Github shows. I'd guess
they run `git gc` at least once in a while. I'll try deleting the
repository, and pushing a clone that was gc'ed locally first instead.

You may want to run the repack with the appropriate options instead of gc
http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/
Since this is a one-time operation, you should run the repack with the -f.
I've played with this on repositories converted from SVN, and I found that
repack tends to do better than gc --aggressive in terms of repository size.

Thanks, I tried this overnight, with the following results:

* A local clone of the .hg/git directory was 1GB (probably due to now having
checked out files too).
* Running `git repack -f -a -d --depth=250 --window=250` brought it back to
395MB.
* I just pushed it to a fresh repository on Github, which shows it as 261MB.
(But it appears to me not all bookmarks/branches were pushed, I only see
master). It's at https://github.com/xnyhps/adium. The other one was moved
to https://github.com/xnyhps/adium-bad.

This is looking quite promising, thanks. :)

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130213/643ef56c/attachment.bin>

[Thijs Alkemade]

Okay, I propose to do the following:

In about a week I will rerun the initialization of hg-git's repository on
one of our servers (probably eider) and set it up to push to and pull from
https://github.com/adium/adium regularly (once every hour, I'd say). I hope
this can be done automatically, in my current hg-git checkout I need to
forcefully set bookmarks every time I try to push something new.

Git is more strict than hg about author names. A couple of our committers
have used a name without an email in the past and without intervention
Github collided all those into invalid-email-address. I've put together this
list: http://hg.adium.im/adium/file/53d3249f0764/authors.txt of those
people, together with email addresses I found in public information. It is
possible to use this list to tell hg-git which email address to use for
people without one.

If you object to this information used on your commits, please let me know
within a week! After running the conversion, the only way to change this
information is to run the conversion again.

Regards,
Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130213/6b9b2af8/attachment.bin>

[Christian Doyle]

Did you happen to run git push origin master, or just git push origin?

git push origin (or whatever you happened to name your remote) will push
all of the branches. In order to push the tags you will need to do git push
origin --tags

Post by Thijs Alkemade

On Tue, Feb 12, 2013 at 5:21 PM, Thijs Alkemade <me at thijsalkema.de>

Post by Thijs Alkemade
Okay, I took a closer look.
* In the repository that ran the conversion, the .hg/git directory is 909MB.
This is a fresh conversion, but might have included a couple of local
commits I never pushed.
It was a fresh conversion, as after I tried `git gc`, hg-git was

unable

Post by Thijs Alkemade
to
push to github. I guess it accidentally deleted something git

considers

Post by Thijs Alkemade
garbage but hg-git doesn't.
xnyhps/adium 2681.82MB
* Cloning that resulted in a 648 MB directory (so working directory
and .git).
* `git gc --aggressive` brought that down to 386 MB.
I don't really know what's going on with the size Github shows. I'd

guess

Post by Thijs Alkemade
they run `git gc` at least once in a while. I'll try deleting the
repository, and pushing a clone that was gc'ed locally first instead.

You may want to run the repack with the appropriate options instead of gc

http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/

Since this is a one-time operation, you should run the repack with the

-f.

I've played with this on repositories converted from SVN, and I found

that

repack tends to do better than gc --aggressive in terms of repository

size.
* A local clone of the .hg/git directory was 1GB (probably due to now having
checked out files too).
* Running `git repack -f -a -d --depth=250 --window=250` brought it back to
395MB.
* I just pushed it to a fresh repository on Github, which shows it as 261MB.
(But it appears to me not all bookmarks/branches were pushed, I only see
master). It's at https://github.com/xnyhps/adium. The other one was moved
to https://github.com/xnyhps/adium-bad.
This is looking quite promising, thanks. :)
Thijs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130214/ed95debf/attachment.html>

[Thijs Alkemade]

Post by Christian Doyle
Did you happen to run git push origin master, or just git push origin?
git push origin (or whatever you happened to name your remote) will push
all of the branches. In order to push the tags you will need to do git push
origin --tags

It wasn't a problem with git(hub), it was a problem with hg not updating the
bookmarks (which determine what becomes a branch in git) automatically when
new commits were pulled in. I've tracked this down to two problems:

Pulling from git suffered from this bug:
https://bitbucket.org/durin42/hg-git/pull-request/14/when-branch_bookmark_suffix-is-set-fix/diff

Pulling from a remote hg repository will only update a bookmark if the
server had that bookmark and changed it. I've updated hg on hg.adium.im to
a version that supports bookmarks (in the yak shaving spree that followed,
I've also updated trac, mercurial-server and hgweb), and pushed a bookmark
for most of our currently open branches.

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130215/fb1a49da/attachment.bin>

[James Gray]

Post by Thijs Alkemade
https://bitbucket.org/durin42/hg-git/pull-request/14/when-branch_bookmark_suffix-is-set-fix/diff

Hi All,

FWIW, I work for the company that owns BitBucket and have a good relationship with the head of the BitBucket team. We are a very Mac-friendly company and I think every OSX user has Adium installed! Given the high-profile of Adium, both in our company and the Mac community in general, if you need something specific from the BitBucket guys, I can go into bat for you and see if there's anything we can do :)

Keep being awesome,

James

[Amelia Rose Khan]

Hello all,

Does this mean we are stuck until that bug gets fixed? Or can we move
forward with this other ways?

Thanks,
Amelia Rose

Post by Thijs Alkemade
https://bitbucket.org/durin42/hg-git/pull-request/14/when-branch_bookmark_suffix-is-set-fix/diff
Hi All,
FWIW, I work for the company that owns BitBucket and have a good
relationship with the head of the BitBucket team. We are a very
Mac-friendly company and I think every OSX user has Adium installed! Given
the high-profile of Adium, both in our company and the Mac community in
general, if you need something specific from the BitBucket guys, I can go
into bat for you and see if there's anything we can do :)
Keep being awesome,
James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130217/5758835c/attachment.html>

[Thijs Alkemade]

Post by James Gray

Post by Thijs Alkemade
https://bitbucket.org/durin42/hg-git/pull-request/14/when-branch_bookmark_suffix-is-set-fix/diff

Hi All,
FWIW, I work for the company that owns BitBucket and have a good relationship with the head of the BitBucket team. We are a very Mac-friendly company and I think every OSX user has Adium installed! Given the high-profile of Adium, both in our company and the Mac community in general, if you need something specific from the BitBucket guys, I can go into bat for you and see if there's anything we can do :)
Keep being awesome,
James

Hi James,

I really appreciate the support Bitbucket has given to Adium over the years
and I like using it myself. However, bringing in more contributors is
a pretty high priority for Adium right now. If adding Github to our mirrors
lowers the bar for even a couple of people to make a small contribution,
then this is a win, in my opinion.

--

Current status: I've reran the conversion on eider with the updated
author-map. `git repack`ing failed a couple of times, probably due to too
high memory usage, but reducing the window size eventually got it to work.
It is now available on https://github.com/adium/adium/. Syncing is still
manual as I haven't exactly figured out how to handle Github and hg.adium.im
diverging properly, and bookmarks still occasionally seem to get lost.

So I think it's ready for the world to try, so now go fork it and send some
pull requests everyone. :)

Regards,
Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130219/eea6697e/attachment.bin>

[Peter Hosey]

So I think it's ready for the world to try, so now go fork it and send some pull requests everyone. :)

If we're keeping the Mercurial repository as our master repository, have you/has anyone verified that changesets make it back from Git to Mercurial correctly (and don't subsequently get re-converted from Mercurial to Git, causing duplicates or other weirdness)?

[Thijs Alkemade]

Post by Peter Hosey

So I think it's ready for the world to try, so now go fork it and send some pull requests everyone. :)

If we're keeping the Mercurial repository as our master repository, have you/has anyone verified that changesets make it back from Git to Mercurial correctly (and don't subsequently get re-converted from Mercurial to Git, causing duplicates or other weirdness)?

Yeah, I did http://hg.adium.im/adium/rev/2808f202d2ef with the Github
website itself. After that I did http://hg.adium.im/adium/rev/5268b37fad0d
locally in hg, and pushed both. Pushing the hg one to Github fails of
course, as both are on master (and merging shouldn't be tried automatically,
I think). But pulling the commit from Github into mercurial worked fine.
I merged it locally into http://hg.adium.im/adium/rev/63097a96adad, pushed
to hg.adium.im and after that everything pushed to Github properly again.

Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 938 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130219/105f16ad/attachment.bin>

[Peter Hosey]

I'm not asserting that other systems don't have helpful features, but I think Github's pull requests are a really nice tool. They make it easy for outside developers to submit patches and do a really nice job of facilitating conversations about code changes.

Moreover, a lot of developers use these tools.

GitHub's great strength is the network effect. It's how, at least in the Mac/iOS community, GitHub with Git won out over Bitbucket with Mercurial (note that Bitbucket now supports Git). Lots of people use GitHub, more than use Bitbucket or GCH.

As one data point, here's my ISO 8601 date formatter on Bitbucket:

https://bitbucket.org/boredzo/iso-8601-parser-unparser

and on GitHub:

https://github.com/boredzo/iso-8601-date-formatter

The BB repo has 25 followers and six forks. The GitHub repo has 71 followers and 20 forks.

The BB repo has also received all of three pull requests. The GitHub repo has that many open right now, plus a fourth one that I've accepted and closed?and this is a much younger repo.

I recognize that changing version control systems and service providers and workflows are all Really Big Deals in their own right, and doing all of those at once is an Even Bigger Deal, but I (as an outside developer) do think it's a thing worth considering.

I've changed two of my Mercurial repoes over to Git (Time Machine Growler and the aforementioned ISO 8601 date formatter), and it's not *nearly* the ordeal that svn?hg was. You could write a shell script for this, wrap it in Platypus, and have a droplet. The hg-git extension for Mercurial makes the job painless.

The harder part would be Trac integration, I think?I don't know what the state of Trac's Git support is. (Plus the ?getting the source? page would need to be updated again, and probably some other things would need doing that I'm forgetting.)

On a semi-related note:

Back when we did that changeover from Subversion to Mercurial, there weren't any good Git GUIs. GitX might have existed, and it was better than nothing, but other than that, the choice was between git(1) and hg(1). I still would prefer hg today given that choice.

But we're not limited to the CLIs anymore. We have several great options for GUIs, and the Git folks themselves even have a great list of them: http://git-scm.com/downloads/guis

I personally use SourceTree, which is free and supports both Git and Mercurial. You could all start using it today on Adium's existing repo, and continue using it if we do move to Git.

[David Smith]

Post by Peter Hosey

I'm not asserting that other systems don't have helpful features, but I think Github's pull requests are a really nice tool. They make it easy for outside developers to submit patches and do a really nice job of facilitating conversations about code changes.

Moreover, a lot of developers use these tools.
GitHub's great strength is the network effect. It's how, at least in the Mac/iOS community, GitHub with Git won out over Bitbucket with Mercurial (note that Bitbucket now supports Git). Lots of people use GitHub, more than use Bitbucket or GCH.
https://bitbucket.org/boredzo/iso-8601-parser-unparser
https://github.com/boredzo/iso-8601-date-formatter
The BB repo has 25 followers and six forks. The GitHub repo has 71 followers and 20 forks.
The BB repo has also received all of three pull requests. The GitHub repo has that many open right now, plus a fourth one that I've accepted and closed?and this is a much younger repo.

I recognize that changing version control systems and service providers and workflows are all Really Big Deals in their own right, and doing all of those at once is an Even Bigger Deal, but I (as an outside developer) do think it's a thing worth considering.

I've changed two of my Mercurial repoes over to Git (Time Machine Growler and the aforementioned ISO 8601 date formatter), and it's not *nearly* the ordeal that svn?hg was. You could write a shell script for this, wrap it in Platypus, and have a droplet. The hg-git extension for Mercurial makes the job painless.
The harder part would be Trac integration, I think?I don't know what the state of Trac's Git support is. (Plus the ?getting the source? page would need to be updated again, and probably some other things would need doing that I'm forgetting.)
Back when we did that changeover from Subversion to Mercurial, there weren't any good Git GUIs. GitX might have existed, and it was better than nothing, but other than that, the choice was between git(1) and hg(1). I still would prefer hg today given that choice.
But we're not limited to the CLIs anymore. We have several great options for GUIs, and the Git folks themselves even have a great list of them: http://git-scm.com/downloads/guis
I personally use SourceTree, which is free and supports both Git and Mercurial. You could all start using it today on Adium's existing repo, and continue using it if we do move to Git.

Which reminds me, updating Adium's ISO 8601 formatter to the latest would be a useful project. NSCalendarDate is terrible.

David

[Peter Hosey]

Post by David Smith
Which reminds me, updating Adium's ISO 8601 formatter to the latest would be a useful project. NSCalendarDate is terrible.

And the new one is much better.

[Alan Humpherys]

Post by Peter Hosey
The harder part would be Trac integration, I think?I don't know what the state of Trac's Git support is. (Plus the ?getting the source? page would need to be updated again, and probably some other things would need doing that I'm forgetting.)

One piece of good news is that version 1.0 of trac now includes GIT as a fully supported VCS.

(http://trac.edgewall.org/ticket/10594)

(Not that I am advocating a change one way or another - LONG LIVE SVN!)

- Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20130212/fb90df1b/attachment-0001.html>

[Joe Hildebrand (jhildebr)]

Post by Thijs Alkemade
This sounds exactly like re-inventing the largefiles extension for hg. ;)
The downside is that we would need to rebuild our repository to include
support for it, otherwise we don't benefit.

One thing to consider is that the GitHub folks might be willing to help,
either with the largefiles approach, or with other things that their
expertise suggests. As well, they might be willing to give you more quota
if you ask.