Version control systems

Version control systems

[Thomas Goirand]

I have opened another thread, as I think that otherwise it's a mess.

>> To me, it would be wise to switch to Git. You would never regret
>> it!!!
>
> Git is just the RCS flavor of the month. I don't see any compelling
> arguments in favor of switching. Subversion might be an alternative to
> CVS, but what do we gain by switching away from a tried and tested
> revision control system which does a perfect job of keeping track of the
> source code?

No, Git is NOT yet-another-RCS, and for sure not only the flavor of the
month. If you were comparing Git to let's say bitkeeper (commercial) or
mercurial (open source), then that would make sense. But Git and HG have
NOTHING to do with CVS or SVN. The work flow is totally different.

By switching to a distributed system like Git you will gain:
- safety (you wont give any write access, updates are done with ssh)
- help when merging patches will be possible (you can delegate this to
somebody else that you trust and simply pull from him ...)
- no network access when you are doing commits
- ease of branching (Git branching is really wonderful and inexpensive)
- a wonderful git-web interface to see the work of everyone
- Unix access rights support (sic! I can't bare that fact in CVS)
- and many more ...

There is no "write access" to the centralized server with Git. Everybody
has read access to all public repository, and write access to only it's
OWN public repository. Then when you want to take a patch from someone,
you just "git pull http://www.example.com/contrib-mlmmj/mlmmj.git", see
if you like the patch, then just "push public" so it goes to another
public repository. If it's you, the "main" author of the project, then
we declare that public repository as the master MLMMJ server. But that's
only truth because we say so.

These are just few general sayings about distributed control version
system, if you want to know why Git is better (or mercurial if you want
to use that one), then you can read this video:

http://video.google.com/videosearch?q=linus+gig&emb=0&aq=-1&oq=linus+gi#q=linus+git&emb=0

You see, I didn't even talk about the fact that this stupid CVS doesn't
even understand what is a Unix file write, or that it's patches are
stored at file level instead as per commit. I could have, but this is
not even the important part. The important part is THE WORK FLOW, and
the fact that it's distributed (eg: anybody can merge changes from anybody).

We spent a long time learning the new concepts. This is really
different, and confusing at start. But I really don't want to go back to
that CVS crap. On the SVN site, we could read "CVS done right". As Linus
said on that video, there is NO WAY to make CVS right, the concept is
bad and that's it.

I hope it was not too boring to read and that I made my point. :)

Thomas

P.S: There are some tools to convert your CVS repo to Git if you don't
want to loose the history.

Re: Version control systems

[Morten K. Poulsen]

On Sat, 2009-03-07 at 03:47 +0800, Thomas Goirand wrote:
> I have opened another thread, as I think that otherwise it's a mess.

Wise decision. This thread will probably end up as a flame war, but
let's try anyway.

First of all, I want to make it clear that this is not personal in any
way. It's not me vs. you; It's CVS vs. Git.

> Git and HG have NOTHING to do with CVS or SVN. The work flow is totally
> different.

It is, however, still just a system for keeping track of your revisions.

> By switching to a distributed system like Git you will gain:
> - safety (you wont give any write access, updates are done with ssh)

Few people have write access today, so that's not an issue.

> - help when merging patches will be possible (you can delegate this to
> somebody else that you trust and simply pull from him ...)

I can't remember ever having a merge conflict in mlmmj.

> - no network access when you are doing commits

True, this is a good thing, but I don't keep you from using Git - as
long as you send me unified diffs.

> - ease of branching (Git branching is really wonderful and inexpensive)

cvs tag -b BRANCH_WHATEVER

> - a wonderful git-web interface to see the work of everyone

We can install viewcvs or something similar, if people want a web
interface.

> - Unix access rights support (sic! I can't bare that fact in CVS)

Is Unix access rights a pro or a con? CVS has it, and it works.

> There is no "write access" to the centralized server with Git.

Christian has write access, and does a very fine job of maintaining the
web interfaces. Why would I give that up?

> Everybody has read access to all public repository

Read access can be arranged, but nobody has requested it.

> when you want to take a patch from someone, you just "git pull
> http://www.example.com/contrib-mlmmj/mlmmj.git", see if you like the
> patch, then just "push public" so it goes to another public
> repository.

As opposed to this?

patch -p1 <~/patch-mlmmj-1.2.16-whatever.diff
cvs ci -m 'added whatever (Whoever)'

> if you want to know why Git is better (or mercurial if you want to use
> that one), then you can read this video:
> 
> http://video.google.com/videosearch?q=linus+gig&emb=0&aq=-1&oq=linus+gi#q=linus+git&emb=0

Thank you. It was interesting, though it didn't convince me.

> You see, I didn't even talk about the fact that this stupid CVS doesn't
> even understand what is a Unix file write

What?

> or that it's patches are stored at file level instead as per commit.

This is a valid argument. It makes file renaming a bit difficult, but I
have spent less time doing this - in my entire life - than I have spent
on writing this e-mail. Subversion does this, so that is an argument in
favor of Subversion.

> The important part is THE WORK FLOW, and the fact that it's distributed
> (eg: anybody can merge changes from anybody).

You make it sound like mlmmj is a huge project with thousands of
developers end as many branches. It is not.

You had access to all the patches that I merged into mlmmj-1.2.16 at the
same time as I had access. They were sent to the mailing list. You could
have applied them to your local Git repository. You could have arranged
Git access with the other contributers. I am not stopping you.

> We spent a long time learning the new concepts. This is really
> different, and confusing at start. But I really don't want to go back
> to that CVS crap. On the SVN site, we could read "CVS done right". As
> Linus said on that video, there is NO WAY to make CVS right, the
> concept is bad and that's it.

Linus Torvalds is a great developer (some claim that he is almost as
great as Theo de Raadt), but "Linus told me that CVS is bad and Git is
good" is not a valid argument.

If the distributions start carrying versions of mlmmj which are branched
so far away from the main repository that merging them is not a simple
matter of applying a small patch set, then yes, I might consider using
Git. Until then, no....

Morten

-- 
Morten K. Poulsen <mopo@fabletech.com>
CTO, FableTech
http://fabletech.com/

Re: Version control systems

[Mads Martin Joergensen]

On 07/03/2009, at 14.53, Morten K. Poulsen wrote:

> First of all, I want to make it clear that this is not personal in any
> way. It's not me vs. you; It's CVS vs. Git.


Guys--the mlmmj development is so little that CVS is fine. But CVS  
sucks hamsters through straws compared to git. It's an amazing piece  
of software and the only true way to fly wrt. source control  
management. It's really good. But CVS is fine for what we need it for-- 
especially since I'm too lazy to convert it to git and set it all up :)

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
  and totally illogical, with just a little bit more effort?"
                                  -- A. P. J.

Re: Version control systems

[Christian Czech]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

I think you have really to try hg or git, to get a feel what is different.

Personally I used rcs for one year and than personally and in company 
cvs for another 13 years until beginning 2006. Than all projects where 
switched to hg  because if several developers are involved especially 
over the internet it is more easy and efficient. I think that mozilla 
for firefox and other projects also switched to hg and other small or 
big projects to git or hg does show that they have some advantages. To 
try something out and keep this changes in your personal repo and maybe 
reuse it at a later time can be quite interesting. You just have your 
personal repo for testing, commiting etc. but not push it to main repo 
maybe at this time. It is much more flexible.

Just convert the cvs repo to hg/mercurial and use it for several weeks 
in parallel. Or maybe just go to the directory where your source is and 
enter:

hg init
hg addremove
hg commit

than you have the current source code in hg and try it for some weeks.

Another point is if you want try something and you have a central repo 
of hg you can just create a directory and enter

hg init
hg pull (with https://path to repo)
hg update
to get a working copy of the source and the repo. If your new changes 
don't work you can just delete the directory. For big tests this is 
quite nice. You just commit to your local repo. If you see that your 
ideas work you can just push them to central repo.

Maybe if you are used to use cvs this sounds complicated but first there 
is also a graphical version you don't need to use command line and 
second after a small amount of time you see that you are much more 
flexible and creative with such an approach like hg or git. I use hg 
because in the past it was more straight forward to use and the windows 
version was in par. Maybe this changed over the years so in general 
there is no big difference if you  use git or hg but cvs is really 
another world. It is not so much different to use but because of the 
centralized nature much less convenient.

It does not matter if you use it for a small or a big project. I really 
recommend just to try. Just spent 2 or 3 ours with hg and you will learn 
a lot and it is also quite interesting. So just give it a try.



[-- Attachment #2: Type: text/html, Size: 2674 bytes --]

Re: Version control systems

[Thomas Goirand]

Hi there!

Thanks for your reply.

To me, there are people that are for using hg and git, and ... the one
that never tried it. All this is not a mater of tastes, as you seem to
feel. Let me reply to what you wrote, and I hope that I will explain
good enough so you understand (I'm not a very good English writer).

Morten K. Poulsen wrote:
> On Sat, 2009-03-07 at 03:47 +0800, Thomas Goirand wrote:
> Wise decision. This thread will probably end up as a flame war, but
> let's try anyway.

Let's be more constructive, ok ? I don't really care for developing
MLMMJ itself, because I wont have a lot of time to invest in it. I am
trying to make the project more attractive to other, and improve your
efficiency. :)

>> Git and HG have NOTHING to do with CVS or SVN. The work flow is totally
>> different.
> 
> It is, however, still just a system for keeping track of your revisions.

Well, CVS just store files with a history, it doesn't do so much...

>> By switching to a distributed system like Git you will gain:
>> - safety (you wont give any write access, updates are done with ssh)
> 
> Few people have write access today, so that's not an issue.

The proposal is that you will NOT NEED write access anymore.

>> - help when merging patches will be possible (you can delegate this to
>> somebody else that you trust and simply pull from him ...)
> 
> I can't remember ever having a merge conflict in mlmmj.

I can't remember seeing branches in MLMMJ, and for the sarge bug, I
would have love to have it. I would have take the tag corresponding to
the version, create a branch, and do "git cherry-pick -x PATCHNUMBER".
Then just send the patched version to sarge proposed updates. So much
more easy than trying to dig with CVS. With CVS I was simply not able to
do this, and MLMMJ was kept in Sarge with a bug. Too bad...

>> - no network access when you are doing commits
> 
> True, this is a good thing, but I don't keep you from using Git - as
> long as you send me unified diffs.

Do you think going back and forth between 2 systems is productive ?

>> - ease of branching (Git branching is really wonderful and inexpensive)
> 
> cvs tag -b BRANCH_WHATEVER

The issue with CVS is not about branching, but about merging patches
between versions. Git is far more superior in that job. And also,
there's no network access by doing it. Quite good if you are using your
laptop in the plane, for example ...

>> - Unix access rights support (sic! I can't bare that fact in CVS)
> 
> Is Unix access rights a pro or a con? CVS has it, and it works.

No it doesn't. Do a local file unix right change, do a commit, and ...
nothing happens on the server. You would need to ssh to the server and
do a chmod there. Quite bad, because it also doesn't track the changes
this way.

>> There is no "write access" to the centralized server with Git.
> 
> Christian has write access, and does a very fine job of maintaining the
> web interfaces. Why would I give that up?

Because you don't need write access AT ALL. It's a broken concept.

>> Everybody has read access to all public repository
> 
> Read access can be arranged, but nobody has requested it.

Maybe because nobody knows there's even a version tracking system ?

>> when you want to take a patch from someone, you just "git pull
>> http://www.example.com/contrib-mlmmj/mlmmj.git", see if you like the
>> patch, then just "push public" so it goes to another public
>> repository.
> 
> As opposed to this?

As opposed to apply a patch, see that it doesn't merge, but has put a
real mess in your development folder by doing so, and can't reverse
unless you pull the full tree again.

> patch -p1 <~/patch-mlmmj-1.2.16-whatever.diff
> cvs ci -m 'added whatever (Whoever)'

Which is REALLY not easy to manage. Also, patch simply applies a diff,
it doesn't do a 3 way merge with merge options...

>> http://video.google.com/videosearch?q=linus+gig&emb=0&aq=-1&oq=linus+gi#q=linus+git&emb=0
> 
> Thank you. It was interesting, though it didn't convince me.

Maybe because Linus is bad at doing conferences.

>> You see, I didn't even talk about the fact that this stupid CVS doesn't
>> even understand what is a Unix file write
> 
> What?

Read what I wrote above.

>> or that it's patches are stored at file level instead as per commit.
> 
> This is a valid argument. It makes file renaming a bit difficult, but I
> have spent less time doing this - in my entire life - than I have spent
> on writing this e-mail. Subversion does this, so that is an argument in
> favor of Subversion.

Why switching to Subversion if you agree to switch to something new ?

>> The important part is THE WORK FLOW, and the fact that it's distributed
>> (eg: anybody can merge changes from anybody).
> 
> You make it sound like mlmmj is a huge project with thousands of
> developers end as many branches. It is not.

So, the smallest the project, the more stupid the tools should be?
That's how the above can be read...

> You had access to all the patches that I merged into mlmmj-1.2.16 at the
> same time as I had access. They were sent to the mailing list. You could
> have applied them to your local Git repository. You could have arranged
> Git access with the other contributers. I am not stopping you.

Why would someone want to do this job in parallel when it can be done by
a single man, once and for all ? This is really an unproductive way of
working.

> Linus Torvalds is a great developer (some claim that he is almost as
> great as Theo de Raadt), but "Linus told me that CVS is bad and Git is
> good" is not a valid argument.

Forget about this one then. I AM saying it, and about a thousands
others, that CVS (and maybe also SVN) is something of the past.

> If the distributions start carrying versions of mlmmj which are branched
> so far away from the main repository that merging them is not a simple
> matter of applying a small patch set, then yes, I might consider using
> Git. Until then, no....

Opposite way. If you don't use Git or HG, then it's not possible to
apply security/bug-fix patches easily to a frozen version, and have some
distribution diverge. As I said above, I was stuck the other time with
Sarge, because of this, and a problematic version of MLMMJ stayed in
Debian for MONTHS until Etch came out. This would have never happen with
a Git system. I would have do a search to see in what commit you patched
what I was needing, and done ... 15 minutes of work at most, including
rebuilding the packages and changing the debian/changelog. Compare that
to being JUST STUCK...

Thomas

Re: Version control systems

[Mads Martin Joergensen]

On 07/03/2009, at 21.21, Thomas Goirand wrote:

> So, the smallest the project, the more stupid the tools should be?
> That's how the above can be read...

Thomas,

Let me elaborate on who we are; we're grumpy old men who are to lazy  
to switch, and thus defend our choices like old men sitting on a bench  
in a park, waving our cane against all by-passers, while cursing the  
modern world.

Only thing not true in the above statement? We're actually not that  
old ;)

P.S Being that I know Morten very well, expect him to really try very  
hard to argue his case, instead of just admitting the above, hehe :)
-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
  and totally illogical, with just a little bit more effort?"
                                  -- A. P. J.

Re: Version control systems

[Christian Laursen]

Mads Martin Joergensen wrote:
> 
> On 07/03/2009, at 21.21, Thomas Goirand wrote:
> 
>> So, the smallest the project, the more stupid the tools should be?
>> That's how the above can be read...
> 
> Thomas,
> 
> Let me elaborate on who we are; we're grumpy old men who are to lazy to 
> switch, and thus defend our choices like old men sitting on a bench in a 
> park, waving our cane against all by-passers, while cursing the modern 
> world.

If it might make people happy, I can take a look at making a git mirror 
of the CVS repository. That way the grumpy old developers won't have to 
change their ways. :)

-- 
Christian Laursen

Re: Version control systems

[Thomas Goirand]

Mads Martin Joergensen wrote:
> Let me elaborate on who we are; we're grumpy old men who are to lazy to
> switch, and thus defend our choices like old men sitting on a bench in a
> park, waving our cane against all by-passers, while cursing the modern
> world.

That was my exact reaction as well when we had to switch to Git, so I
understand it perfectly. However, I do not regret the invested time.

Thomas

Re: Version control systems

[Mads Martin Joergensen]

On 08/03/2009, at 00.05, Christian Laursen wrote:

>> Let me elaborate on who we are; we're grumpy old men who are to  
>> lazy to switch, and thus defend our choices like old men sitting on  
>> a bench in a park, waving our cane against all by-passers, while  
>> cursing the modern world.
>
> If it might make people happy, I can take a look at making a git  
> mirror of the CVS repository. That way the grumpy old developers  
> won't have to change their ways. :)


Sounds excellent.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
  and totally illogical, with just a little bit more effort?"
                                  -- A. P. J.