I have used cvs and later svn, and never really have needed DVCS. Still, I
have projects in both GitHub and BitBucket using Git (I never got around
using mercurial - so I don't know which is better). CVS was quirky and
buggy, but I never had any problems with SVN which is straightforward and
easy to work with. Migrating to git, on the other hand, and as has been
previously mentioned took some effort - but this is mostly because I come
from the simplicity of SVN. The trick is thinking in terms of your local
repo. Some time ago I made some research on github vs bitbucket and at the
time we found that bitbucket was inferior as a product but we ended up
going for that because of the private repositories. After the UI rewrite
of Bitbucket in 2012 - I find the two mostly equivalent even if the
bitbucket wiki is pretty unsophisticated (so is GutHubs but at least I have
never lost pages in the GitHub one). Greg feels uneasy because of the
trend factor - but both GIT (isn't it used for the Linux kernel?) and
github are well proven projects with a community the size of St. Petersburg.
Either way you go (git vs mercurial, github vs bitbucket) I will be the
first one to celebrate the fact that RDKit is moving away from sourceforge
and its crappy, lousy, 2001 look and feel, unresponsive, Ad-ridden,
unusable interface. For the talk I gave at the user meeting I had to count
the number of posts I created, and I ended up counting them manually in the
archives as there was no obvious way how to do it. To this day that
interface makes me cringe.
p.s. I agree with Eddie, +1 for "Git changes the way you think, the same
thing learning functional programming would do to you."
-
Jean-Paul Ebejer
Early Stage Researcher
On 2 February 2013 07:00, Eddie Cao <[email protected]> wrote:
> Hi,
>
> As a switcher, I feel I should share my experience.
>
> I am never a power user of any VCS, but I've used RCS, CVS, Subversion,
> Mercurial and Git, and my level is always best characterized as *barely
> enough to get work done*. I chose Mercurial instead of Git during my
> first encounter with the concept of DVCS, mostly because the belief that
> "they two are pretty much the same", and also, because I am a Python
> person, choosing Mercurial seems like a loyal thing to do. I sticked with
> Mercurial for over three years, and resisted the hype around Git and
> Github. My understanding of Git stayed at the level of believing "rebase is
> evil, and hg is safer", "staging area solves a problem I don't have", and
> "mercurial can do that too, with these extensions".
>
> This was until my wife started to use Git for work, and rave about it. So
> I checked it out.
>
> And I switched. Not because there are things that are inherently
> impossible in Mercurial, but there is a culture component of Git that
> emerges around an open door design (which Python does too and proudly
> labels it as *a language for adults*).
>
> For example, Git infuses this attitude into you that commit quality is as
> important as your code quality, and Git is optimized to make beautiful
> commits. With Git, you tend to *compose* and *edit* commits carefully as
> you would write beautiful and elegant code. Have uncommitted changes in one
> file deal with two irrelevant bugs? Easily make two separate commits by
> picking lines to commit. Have uncommitted changes but there is an emergent
> bug to fix? Avoid a half-baked commit by simply stashing your changes and
> reverse it when you are done with the bugfix. Some seems to fear the power
> to rewrite history, but it is a very powerful tool. Have a commit that just
> corrects a typo? You can combine it with an earlier commit. Regret that the
> summary of a previous commit is not clear enough? You can edit that
> message.
>
> The learning curve is absolutely steeper for Git for people with prior
> knowledge of other VCS. This is mostly because Linus' vision about Git is a
> file system on top of a file system<http://git-scm.com/book/en/Git-Internals>
> and
> he did not try to emulate existing VCS systems. However, if you want to
> support real distributed workflow, I would argue Git and Mercurial require
> the same amount of learning, as you could see in the comparison in PEP
> 374<http://www.python.org/dev/peps/pep-0374/#one-off-checkout>. But
> if you care about commit history as much as you care about code quality -
> and I believe commit history is essential in distributed collaborative
> workflow enabled by a DVCS - then you will appreciate the Git workflow and
> the Git way.
>
> And bonus: Git changes the way you think, the same thing learning
> functional programming would do to you.
>
> Regards,
> Eddie
>
>
> On Feb 1, 2013, at 10:17 AM, Patrick Fuller wrote:
>
> Seconding Markus - My biggest issue switching from svn to git was honestly
> the word "checkout". It means two different things between them, and I
> found myself doing stupid things all the time. Outside of that, and the
> weird "staging area" thing I never got a hold of but can be easily skipped,
> I didn't think it was all that terrible of a switch.
>
>
> On Fri, Feb 1, 2013 at 10:53 AM, Markus Sitzmann
> <[email protected]>wrote:
>
>> I started with CVS, switch to svn, tried to learn git which made my head
>> explode. However, for some odd reasons I didn't gave up on git, and one
>> day
>> it make click. Since then I switched everything to git and never looked
>> back. I agree, when you come from CVS and svn, git changes your way of
>> thinking. It is probably easier to start right away with git - but its
>> concept is more logic.
>>
>>
>>
>> On Fri, 01 Feb 2013 11:23:57 -0500, greg landrum <[email protected]>
>> wrote:
>>
>> > You ask an excellent question. I will provide my two cents, from the
>> > context of someone who has been saying "DVCS solves a problem I don't
>> > have" for a couple years now.
>> >
>> > There is definitely a big learning curve for those of us who have been
>> > using cvs/svn for years (I think it may be more difficult for an svn
>> > user to switch to fit than for someone who has never used version
>> > control to learn it); that's a strike against git. It's also super
>> > trendy, which makes me nervous. Finally, a lot of the criticisms that
>> > git zealots make of svn are poorly informed and/or based on old versions
>> > of svn. (Finally+1: the iOS spelling correction really seems to hate
>> > "git")
>> >
>> > Having said all that, git and related systems do make it much easier for
>> > other people to contribute to an open source project because they allow
>> > the others to use source control to track their changes without them
>> > having to have commit access to the main code repository. There are some
>> > other advantages (among them having access to version control while
>> > offline) but that one is just a giant plus. Technically people could
>> > also accomplish that using svn and a vendor branch, but that is a pretty
>> > large pain and would not help with merging their changes/additions into
>> > the core when the time comes for that.
>> >
>> > -greg
>> >
>> > On Feb 1, 2013, at 4:10 PM, "Igor Filippov [Contr]"
>> > <[email protected]> wrote:
>> >
>> >> Rant
>> >>
>> >> I tried working with git naively thinking I'll figure it out on the go
>> >> (after long working with CVS and SVN). Nothing doing. Then I found a
>> few
>> >> tutorials. The description of detached heads and other arcana made my
>> >> brain explode.
>> >> Why does version control need to be so complex?
>> >> Do we really need it for projects not involving thousands of developers
>> >> and millions lines of code?
>> >>
>> >> /Rant
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_d2d_jan
>> > _______________________________________________
>> > Rdkit-discuss mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>> _______________________________________________
>> Rdkit-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
>
> http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________
> Rdkit-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Rdkit-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Rdkit-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
