Moving to Hg without any analysis at all

[Eoin Coffey]

On Mon, Feb 7, 2011 at 10:09 PM, Christopher Forsythe <chris at growl.info> wrote:
>
>
> On Mon, Feb 7, 2011 at 11:04 PM, Eoin Coffey <ecoffey at gmail.com> wrote:
>>
>> On Mon, Feb 7, 2011 at 9:49 PM, Christopher Forsythe <chris at growl.info>
>> wrote:
>> >
>> >
>> > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras
>> > <felipe.contreras at gmail.com> wrote:
>> >>
>> >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D.
>> >> <evan.s at dreskin.net> wrote:
>> >> >
>> >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote:
>> >> >
>> >> >> What you are basically saying is: monotone the tool we know, and we
>> >> >> are comfortable with
>> >> >
>> >> > This is a perfectly good reason, by itself, when combined with "and
>> >> > monotone can do the job we want it to do."  Time is our most precious
>> >> > asset.
>> >>
>> >> Ah, some honesty. That's all I'm saying; if you don't want to do a
>> >> careful analysis, fine, just say so. If mercurial turns out not to be
>> >> the best choice, don't claim you did a careful analysis, because there
>> >> isn't any.
>> >>
>> >> And yeah, that's a perfectly good reason... for a weekend project. I
>> >> still maintain that the last analysis (that resulted in monotone
>> >> chosen as the tool) was not done correctly (the main argument was the
>> >> big space, and nobody bothered to ask how to reduce it; git-repack),
>> >> and back at that time people said that before choosing another tool, a
>> >> careful analysis would need to be done, so that the right tool is
>> >> picked. I guess talk is cheap.
>> >>
>> >
>> >
>> > Adium did do an analysis like you are suggesting, back in 2009 they
>> > switched
>> > to mercurial
>> > http://trac.adium.im/wiki/DistributedVersionControl
>> > I do not believe that the pidgin guys will change their minds at this
>> > point.
>> > However, I do think that you could aleviate Evan's point here Felipe.
>> > You
>> > (or someone else) could maintain a very in depth list of pros and cons
>> > of
>> > all currently popular version systems. I believe the best way to do this
>> > would be to remain objective, and be pedantic. If an in depth analysis
>> > existed like this now, I believe what you are arguing for would not be
>> > an
>> > issue. There are new things to bring up, such as the hg-git command to
>> > access git repos, and conversion problems that could all be well
>> > documented.
>> > Plus for extra credit a beginner's guide to each version control system,
>> > with examples of how to do each thing and also a separate document
>> > explaining differences in the version control system, would really make
>> > this
>> > decision for *every single oss project out there*.
>> > That all said, I vote for mercurial (as if my vote matters). I hate git
>> > error messages when I get them (no need to reply to this point, my
>> > opinion
>> > won't change here).
>> > Chris
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at pidgin.im
>> > http://pidgin.im/cgi-bin/mailman/listinfo/devel
>> >
>> >
>>
>> Something else entirely to consider is the killer app that is github.
>> More and more open source projects are hosting their official repo
>> there.  The UI is quick and efficient, lots of great features (pull
>> requests, git enabled wikis, and issues come to mind).  If someone
>> ever gets tired of hosting all the infrastructure, github would do a
>> lot of that work for you :-)
>
>
>
> I'll replace your paragraph with one of my own, using your words with my
> regular expression changes. It's computer magic! ;)
>
>
> s/git/mercurial/
> s/github/google code hosting/
> Alternatively:
> s/git/mercurial/
> s/github/bitbucket/
>
>
> You can go on and on :)
>
>

Heh, I see what you're saying, but GitHub has been the most enjoyable
code hosting solution for me; granted I haven't used bitbucket that
extensively.