Re: Version control systems

[Thomas Goirand <thomas@goirand.fr>]

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