T
thiagobrandam
Does anyone know any good revision control tool/software for Ruby?
Thanks in advance.
Thanks in advance.
J
James Dinkel
thiagobrandam said:
I use a subversion server (running on a linux server) and connect to it
through the Subclipse plugin to Eclipse. If you don't want a separate
server, you can create a local svn repo on your workstation and connect
directly to it through the Subclipse or any other svn client.
James
M
Mark Thomas
R
Robert Klemme
2008/9/30 thiagobrandam said:
I use rcs locally on cygwin.
robert
M
Mike Gold
Robert said:
Ah, so that's what they were talking about. You see, I got a call from
1991 today--they were looking for their version control system. I'm
glad you found it!
T
twinandi
thiagobrandam said:
I love Mercurial (http://www.selenic.com/mercurial/wiki/). It's distributed,
really fast and available for Linux MAC OS X AND Windows (contrary to Git).
Via TortoiseHg it gets integrated into Windows File-Explorer (like
TortoiseSVN).
For deployment-Reasons (Rails) i also use SVN, but i think deployment is
also possible via Mercurial.
Andi
P.S. Please excuse my very poor English-speaking (writing)
O
Ollivier Robert
And it is nicely integrated in things like Redmine and Trac as development
platforms.
R
Ron Fox
I guess the point is that any old revision control system will do.thiagobrandam said:
None of them are specific to the language you use to write your
software. Pick one use it if you don't like it pick a different one
for the next project. Repeat until you like one.
J
Joe Wölfel
Depending how you work I think safety and productivity improvements
can be large with many of the newer systems. There are several that
are worth a look. I've used Mercurial a little in the past and liked
it. I also use Bazaar a lot and find it easy to use and very
powerful. Probably the biggest issue I have with Bazaar is that a
plugin is required to use external diff tools. It's no big deal, but
that probably ought to be standard. I'm wondering if git is gaining
the most momentum in the Ruby community. Maybe that matters. On
Windows git might still depend on Cygwin, although I've heard this
might not be true anymore. All of these tools offer large
improvements over Subversion and CVS. I would avoid older designs
like those used in Subversion and CVS.
can be large with many of the newer systems. There are several that
are worth a look. I've used Mercurial a little in the past and liked
it. I also use Bazaar a lot and find it easy to use and very
powerful. Probably the biggest issue I have with Bazaar is that a
plugin is required to use external diff tools. It's no big deal, but
that probably ought to be standard. I'm wondering if git is gaining
the most momentum in the Ruby community. Maybe that matters. On
Windows git might still depend on Cygwin, although I've heard this
might not be true anymore. All of these tools offer large
improvements over Subversion and CVS. I would avoid older designs
like those used in Subversion and CVS.
I
Ittay Dror
since nobody else mentioned it, i think git is great. it is athiagobrandam said:
distributed vcs (like mercurial), with a much better branch/merge
support than svn and a lot of power commands to allow you to make your
commits organized. there's also github which offers hosting for git
repositories and seems to be very popular with git developers (rails is
hosted there)
ittay
J
Joe Wölfel
I think I mentioned git. In fact, I received a git patch for Rake
over this list serve a only few days ago. It's really good compared
to the way things used to be in the pre-distributed days. I just had
git suck the patch right out of my email and it applied it to my
local Rake repository. Very nice.
over this list serve a only few days ago. It's really good compared
to the way things used to be in the pre-distributed days. I just had
git suck the patch right out of my email and it applied it to my
local Rake repository. Very nice.
D
David Masover
Which part? The "distributed", the "really fast", or the cross-platform?
Git works natively on Linux and OS X, and has a mingw32 port for Windows.
Whether mingw32 is "native" is up for debate, but it's certainly more native
(and faster!) than Cygwin.
Git is also just about the fastest SCM I've EVER used -- not that I've
benchmarked, but I very much doubt Mercurial (being written in Python) has it
beat.
And yes, Git is distributed.
Deployment is possible via just about anything you want. The only real
limitation is what you're deploying to, or how much you're allowed to muck
with the deployment process.
Keep in mind that Rails itself is developed on Git, and the Rails source is on
Github. So yes, Capistrano does support several flavors of Git deployments,
and I wouldn't be surprised if there was also a Mercurial plugin.
D
David Masover
I'm going to go against pretty much everyone else in this thread and say "No."
Ruby, like most programming languages, keeps source code as plain text.
Most revision control tools work with plain text.
So I know of all kinds of good "revision control tools" (or "Source Control
Management", if you like), but none specifically "for Ruby", in any sense.
None of them are written in Ruby, and all of them will work equally well for
any language which stores its source code as plain text.
That said, Rails recently moved from Subversion to Git. Since then, there
seems to be a stampede of Ruby projects moving to Git, and all kinds of tiny
projects hosted on Github.
R
Robert Klemme
Funny that you mention "stampede". The longer I watch communities of
people the more I am convinced that "herd" is an adequate description of
how they behave most of the time. Just think about the current
financial crisis... More often than not hype or publicity seem to steer
behavior of larger groups of people instead of reasoning.
Note: I am not saying that Git is bad or anything. I just talk about an
impression I have about a general pattern of behavior. The same
reasoning could be applied to web frameworks etc.
Kind regards
robert
T
twinandi
David said:
The combination of all of them ... mostly the cross-platform-thing ...the distribution makes life easier ... and the Speed ... hmm... for me
thats not THAT critical.
I've tried Git a few Weeks ago, and yes it's speed on really large
repositories iss probably unbeatable (for now?) Because of the "Git-hype"
(everyone speaks about it, its initially made by Linus ... woooah
, Railsswitched to Git, Github was launched, etc. ) i first tried to use Git and
later switched over to Mercurial, because sometimes i have to use Windows,
just because a Linux is not available. And then i think Mercurial is easier
(for me!) to install. Just windoze-double-click.
So the easy cross-platform-use is the really cause, why i decided to use
mercurial internal instead of Git.
I think i have to dig deeper in capistrano, off the beaten track. And/or i
should try Git again ...
As everytime it gets to a decission wether to use Software A or Software B,
in the end its just subjective
Andi
T
thiagobrandam
Thank you guys. I didn't know my doubt would generate such rich
discussion. This semester I'm having OOP classes
and as a final exam, we will have to build a software using OO
concepts. As this is pretty much the first time my group
will have to deal with revision management. We decided to program in
Ruby (solely, no Rails at all) and we were wondering if there was
such thing
as a good revision control tool that best fits our needs (turns out it
doesn't according to the discussion...). We talked to our teacher
and he decided that the Subversion repository of Google Code would be
the standard for all groups. Thanks once again for all the help. I
found
Robert Klemme's and David Masover's opinions particularly interesting.
Help us think about hypeXreasoning issues and focus on what really
matters.
Thiago
discussion. This semester I'm having OOP classes
and as a final exam, we will have to build a software using OO
concepts. As this is pretty much the first time my group
will have to deal with revision management. We decided to program in
Ruby (solely, no Rails at all) and we were wondering if there was
such thing
as a good revision control tool that best fits our needs (turns out it
doesn't according to the discussion...). We talked to our teacher
and he decided that the Subversion repository of Google Code would be
the standard for all groups. Thanks once again for all the help. I
found
Robert Klemme's and David Masover's opinions particularly interesting.
Help us think about hypeXreasoning issues and focus on what really
matters.
Thiago
J
Joe Wölfel
Ok. Maybe it's useful to have a devil's advocate position here.
There's often a form of argument that says there's really not much of
a difference between languages, tools, etc., that it's simply a
matter of taste any anyone could be just as productive, successful,
happy, etc., regardless of the actual tool choices. I'm going to say
that this is usually a way of avoiding thinking about the problem and
dismissing the opportunity costs by not examining them.
Version control systems do interact with languages. If you we're
working with an IDE oriented language like Java you might be limited
to whatever VCS works with your IDE. Since you're working with Ruby,
which isn't typically developed using IDE refactoring tools, you have
more freedom. Many people choose their VCS for these kinds of
legacy reasons. It doesn't sound like you have to.
Choosing Subversion for Ruby, while it certainly won't kill you, I
think is a missed opportunity to explore more modern development
environments and ways of working with others. For an idea of this,
here's a talk that's well worth listening to: http://www.youtube.com/
watch?v=4XpnKHJAok8. Torvalds uses strong language when he
discusses Subversion, as is his style, but he's bright guy, he's been
extremely successful in managing important software development
projects, he's spent a good amount of time thinking about the
problem, and he's far from alone in his thinking.
Whether you choose something like Git, Mercurial, Bazaar, or even
Darcs, I think you'll end up learning some useful concepts of growing
importance that you can't learn with CVS or Subversion and it won't
cost you anything.
There's often a form of argument that says there's really not much of
a difference between languages, tools, etc., that it's simply a
matter of taste any anyone could be just as productive, successful,
happy, etc., regardless of the actual tool choices. I'm going to say
that this is usually a way of avoiding thinking about the problem and
dismissing the opportunity costs by not examining them.
Version control systems do interact with languages. If you we're
working with an IDE oriented language like Java you might be limited
to whatever VCS works with your IDE. Since you're working with Ruby,
which isn't typically developed using IDE refactoring tools, you have
more freedom. Many people choose their VCS for these kinds of
legacy reasons. It doesn't sound like you have to.
Choosing Subversion for Ruby, while it certainly won't kill you, I
think is a missed opportunity to explore more modern development
environments and ways of working with others. For an idea of this,
here's a talk that's well worth listening to: http://www.youtube.com/
watch?v=4XpnKHJAok8. Torvalds uses strong language when he
discusses Subversion, as is his style, but he's bright guy, he's been
extremely successful in managing important software development
projects, he's spent a good amount of time thinking about the
problem, and he's far from alone in his thinking.
Whether you choose something like Git, Mercurial, Bazaar, or even
Darcs, I think you'll end up learning some useful concepts of growing
importance that you can't learn with CVS or Subversion and it won't
cost you anything.
J
James Gray
I'm drinking deep from the Git Koolaid, but it always surprises me to =20=
see how often this video is recommended. It's just terrible. Linus =20
doesn't really say anything of value in here. Well, to be fair, his =20
"circle of trust" tangent is very interesting, but has little to do =20
with Git.
Anyway, my opinion is that Git is great and you need to check it out, =20=
but this video is entirely skippable.
James Edward Gray II
J
Joe Wölfel
I have to disagree. It isn't concise, but there's a lot of insight =20
and history here. Also, unlike many of the more theoretical =20
discussions, this talk ties into one of the world's most successful =20
software development projects and the importance of version control =20
with respect to its development. It may be that you have to look =20
below the surface a bit. Notice for example, that in the early days =20=
Torvalds used tarballs and diffs instead of the dominant open source =20
tool CVS. A shockingly choice, but less so if you're familiar with =20=
the design of CVS and the requirements of the project.
Anyway, the point of the talk isn't git. I didn't propose it as a =20
pitch for git specifically. If you read a bit between the lines you =20
see that the talk is about how software development and version =20
control interact. But if you have other discussions you think are =20
really good then please post them.
and history here. Also, unlike many of the more theoretical =20
discussions, this talk ties into one of the world's most successful =20
software development projects and the importance of version control =20
with respect to its development. It may be that you have to look =20
below the surface a bit. Notice for example, that in the early days =20=
Torvalds used tarballs and diffs instead of the dominant open source =20
tool CVS. A shockingly choice, but less so if you're familiar with =20=
the design of CVS and the requirements of the project.
Anyway, the point of the talk isn't git. I didn't propose it as a =20
pitch for git specifically. If you read a bit between the lines you =20
see that the talk is about how software development and version =20
control interact. But if you have other discussions you think are =20
really good then please post them.
B
brabuhr
You can still experiment with something like git if you should desire:
http://utsl.gen.nz/talks/git-svn/intro.html
http://www.viget.com/extend/effectively-using-git-with-subversion/
I generally use git for all my projects and use git-svn when I need to
pull something from or publish something to our centralized corporate
subversion server.