Re: [Rails-devel] Idea: migrating away from cvs.

[brett l. <wak...@gm...>]

On Wed, Feb 3, 2010 at 2:17 PM, John A. Tamplin <ja...@ja...> wrote:
> On Wed, Feb 3, 2010 at 5:02 PM, brett lentz <wak...@gm...> wrote:
>>
>> I've personally got experience with CVS, Subversion, and Git. I've
>> only used Mercurial once or twice, which isn't enough to really have
>> an opinion of it.
>>
>> Overall, my experience is that Git is light years ahead of CVS and
>> Subversion.
>
> I would agree CVS is ancient and to be avoided in anything but personal
> projects.
> Between git and svn, I would say it depends on what you are doing.  I am a
> long time Unix user, and to me git feels like the Unix command line
> philosophy -- lots of small tools that you piece together to get what you
> want.  That is good in some ways in that you gain a lot of flexibility in
> how you put the pieces together, but it is bad in that it feels lower level
> and you have to do more steps for common tasks.  The other big difference is
> it is more of a distributed model, where individual people can have their
> own repositories and commit to them, which is good when they aren't
> contributors in the main project.  I don't know about Sourceforge's svn
> controls, but at least on code.google.com you can't have people with commit
> access to subtrees of the repository, which is how svn users accomplish
> similar tasks by having their own change branches for large changes.  That
> means you have to give them commit access anyway and trust that they won't
> commit elsewhere without proper review, but you can always rollback any
> changes that shouldn't have been made and revoke commit access if they do.
>
> --
> John A. Tamplin


It seems that many people get hung up on the "distributed" piece when
talking about git, hg, and bzr.

Really, the only thing being "distributed" means, is that there's no
technical restrictions that enforce a client/server model.

However, it's still very easy to have a development model that
designates one repository as "master" or "authoritative", and have
everyone's commits funnel through that repository.

That's actually what we do at $dayjob. We have a central git
repository server that everyone pushes their changes into.  We don't
publish our personal repositories for merging our various development
trees.  We can, we just don't.  For our use case, it just wouldn't
help us any.

So... other than being able to share your work before it goes into the
"master" tree, the whole distributed thing isn't really a big deal.


---Brett.