Why not move Lazarus Project to Git?

[99Percent]

I know there is someone maintaining a git repository of Lazarus that updates it automatically every 15 minutes, http://wiki.lazarus.freepascal.org/git_mirrors but it misses the whole issue tracking, and all available branches.

Git seems so much more transparent, faster, and easier to use. I think it would attract a lot more developers and debuggers if we officially moved the whole Lazarus project to Git instead of using the now oh, so archaic SVN.

[lainz]

The only thing I can say is that's true, submitting files to SVN (in my case) is slowest than submitting with Git (Tortoise SVN / Tortoise Git). SVN take more time.

[Martin_fr]

Never mind which of them is better or more suitable or whatever...
IMHO those are just the wrong arguments?

Unless you are a committer, why do you care if it takes a few seconds more or less to do a commit?
Even if you are a committer (and I am speaking from experience), what does it matter? It usually takes some hours, days, sometimes weeks to write the code, what does it matter, if it is committed in a one second or a few more (even if it were a minute).

If you are a user, and just want the latest features, and you prefer revision control over snapshots, then still I do not see what it matters?
So ok, you can checkout a little bit faster. But most people who have trouble using Lazarus from SVN are not having the issue with actually using SVN. The issues start with setting up the first installation, putting config together, using a secondary location for --primar-config-path. And all that is not SVN related.

Also if someone wants to become a developer, there are many other hurdles.
How is it relevant to the reasons given in the previous 2 posts?

There may be a few things were it would make a difference.

Obviously, if we had a lot of users who would help finding revisions that broke a feature, and who would therefore have to very quickly test a big amount of revisions, then download times may count (though they fade, compared to the time it may take to recompile after each revision update...)

The question is, would GIT really bring that sudden big amount of people willing, able and ready to to this kind of testing?

For all the rest, it is down do those actually using it

[Ask]

Well, I can tell from my own experience (and I am using git for everything except Lazarus).

The fact that Lazarus uses SVN:
1) Prevents me from seriously contributing to any area where I do not have commit access (basically, everything except TAChart)
2) Prevents me from doing any meaningful work with history (thankfully, there is Graeme's git mirror, but obviously this is not "using SVN" any more)
3) Hinders backporting of fixes to the stable branch (for a recent example, SVN failed to back-port the latest batch of TAChart fixes, so I had to use Git, and Vincent had to use plain diff+patch).

[felipemdc]

AFAIK we are not changing and GIT makes no sense in a limited resources project like ours.

Having 1 bizillion branches means that they all should be tested. If they are not tested by anyone except the original developer, he could just as well make a copy of lazarusvn in which we works out his feature until he has 1 final patch for it. The only difference is versioning in between which is not that of a much have to compensate for all other problems that GIT brings, like being a resource hug, wasting huge amounts of diskspace, being so slow to switch between branches, etc.

1) Prevents me from seriously contributing to any area where I do not have commit access (basically, everything except TAChart)

You can always ask for more permissions. I think it should be fine, provided that you agree to fix any regressions that you introduce in a timely manner (which can be done either by fixing or by reverting).

[Ask]

GIT makes no sense in a limited resources project like ours

That's strange argument. Just look at the github -- there are tens of thousands "zero-resource" projects, and they have now problems using Git.
What kind of limited resource would in your opinion Git consume?

he could just as well make a copy of lazarusvn in which we works out his feature until he has 1 final patch for it

Yeah, and then have the patch rejected (or blindly applied despite its shortcomings) because it is too large to review.
This is one of the serious barriers for Lazarus/fpc development.
Just look at the current unicode string mess in FPC trunk --
and this is a feature developed by core team, not some outside contributor!

problems that GIT brings, like being a resource hug, wasting huge amounts of diskspace, being so slow to switch between branches

You got it backwards (or is it a typo?) -- the above list of problems is precisely the
problems of SVN compared to Git.

AFAIK, the main argument against switching is simply that the core developers
do not want it.
Which choice, even if technically inferior, they are certainly entitled to make.

[felipemdc]

What kind of limited resource would in your opinion Git consume?

Testers for the 1 bizillion branches. Who guarantees their quality? The original coder? =D

Yeah, and then have the patch rejected (or blindly applied despite its shortcomings) because it is too large to review. This is one of the serious barriers for Lazarus/fpc development.

How is GIT any different here? If you merge stuff which was not properly tested you will get into trouble. You still need to test and review everything. The real issue not at all GIT vs SVN it is simply that we lack resources in terms of patch testing and regression and smoke testing for patches.

How it works now can at most be annoying to people that are prefer GIT. If we change then it would get annoying to people that prefer SVN.

Just look at the current unicode string mess in FPC trunk --
and this is a feature developed by core team, not some outside contributor!

Not at all related to SVN vs GIT.

The feature was developed in a branch and then merged into trunk to get feedback, to be able to move it forward, because otherwise no-one tests the branches. How would GIT solve this? By not merging? Would then people magically be inclined to test the branch?

You got it backwards (or is it a typo?) -- the above list of problems is precisely the
problems of SVN compared to Git.

It is not a typo, it's my experience at work wainting hours to download the immense repository and waiting endlessly for branch changes. I didn't want to do any frenetic branch changing, I just wanted to create a patch against master ... and it proved to require a ridiculously high amount of diskspace and time, despite the project sources not being nearly that big, because you are forced to download 1 bizilion wierd branches.

Also you cannot get 2 branches at the same time. If you want, then you need to download yet again all the 1 biziliion branches into a new directory.

[jarto]

AFAIK we are not changing and GIT makes no sense in a limited resources project like ours.

Having 1 bizillion branches means that they all should be tested. If they are not tested by anyone except the original developer, he could just as well make a copy of lazarusvn in which we works out his feature until he has 1 final patch for it. The only difference is versioning in between which is not that of a much have to compensate for all other problems that GIT brings, like being a resource hug, wasting huge amounts of diskspace, being so slow to switch between branches, etc

Even if you use Git and let people create lots of branches, you don't have to test every one of them. It makes sense to limit the the number of official branches (which you test), but there's no idea in restricting how many local branches developers can create on their own workstation.

Git is wonderful, when you switch between branches and merge branches. I have an old lazarus branch, that I worked on 1.5 years ago. So I decided to do a small test:

- switching between my old branch and current lazarus version: 2 seconds
- merge 1.5 years worth of changes to my local branch
  - view all the changes, that will be merged: 1 second
  - merge the changes to my local branch: 3 seconds

[marcov]

We've had tens of such remarks (usually from Graeme) in the last years.

The counter question was always:

- do research that the current workflow can be preserved,
- deal with platform specific issues
- prepare a plan for migration
- test it on a copy.
- Don't forget side tooling like
     - the mergelogs of FPC,
     - Lazarus retrieving the revision for display in the IDE
     - viewvc

and document everything. To people that think this is unfair: the CVS->SVN migration went exactly the same, with Peter doing enormous amounts of work for it.

One time, Graeme actually responded a bit, and then it turned out there were some problems with lineendings (every commit had to make sure that his local system was
configured properly, while in SVN you can centrally force correct lineendings), and also the windows client support was not there.

Personally I also miss the advantage of memorizable revisions in communication in GIT, since it seems to work with unwieldy hashes. But there might be a substitute that I don't know of.

Of course GIT is a moving target too, and these issues might be (partially?) outdated, but the main point is, that if this is going to happen, what is needed is somebody (preferably an experienced committer) doing a very thorough investigation, and willing to take on the migration work. (and you can easily reserve a year's free time for it).

This constant nagging and advocacy is totally futile since it only raises points that are already known. And the committers are reminded of this daily (e.g. now, during release building times when doing the branch checkout is often the rate determining step, which could be sped up significantly with a local read-only server)

So if you really want this, start documenting and testing, and stop the gratuituous nagging.

(updated)

[BigChimp]

I had some negative experiences with Git lineendings on a Windows platform for patches, too. These might disappear if we switch to a Git only environment, but I doubt it.

And actually I don't really care, because...
Futher, basically what Martin said: why change something if it works.

To me, a much more important issue is getting more people to be committers that can deal with bugreports and features...

Just my view,
BigChimp

[lainz]

Unless you are a committer, why do you care if it takes a few seconds more or less to do a commit?

That's ok, I'm not a commiter and the small things I've contributed in the bugtracker was using .diff

Futher, basically what Martin said: why change something if it works.

To me, a much more important issue is getting more people to be committers that can deal with bugreports and features...

Just my view,
BigChimp

Up. And if change from SVN to GIT takes a lot of time, I prefer bug fixes in the current way.

[JuhaManninen]

It is not a typo, it's my experience at work wainting hours to download the immense repository and waiting endlessly for branch changes. I didn't want to do any frenetic branch changing, I just wanted to create a patch against master ... and it proved to require a ridiculously high amount of diskspace and time, despite the project sources not being nearly that big, because you are forced to download 1 bizilion wierd branches.

Also you cannot get 2 branches at the same time. If you want, then you need to download yet again all the 1 biziliion branches into a new directory.

I must comment on this one. You must be doing something seriously wrong Felipe.
Apparently you are not switching a local branch but you are fetching from a remote server, which is also fast with git because it moves only compressed diffs.
Or, do you use git-svn link to fetch from SVN server, but you configured it wrong?
In my experience the only real slow operation with git was the initial cloning of Lazarus SVN repository using git-svn link.
I have documented it here:
  http://wiki.lazarus.freepascal.org/Lazarus_git-svn

But, I don't see a reason to have another religious war between these tools (I hope Graeme doesn't notice this thread ... .
Instead I would suggest to improve the Lazarus git mirror so it includes all branches and has "master" branch following SVN trunk (now Graeme's mirror has "upstream" branch for that).
I can contact Graeme for that. Does someone else have a server available for this purpose in case Graeme  is busy and can't change it? I personally don't have.
Then I would suggest working in a distributed manner with the people who want it. That is the way git was designed to work.

Git could really help in 2 things:

1. Manage local branches for people who want to experiment with code, and do it for more than 1 feature.
  This must be possible with SVN, too, but I honestly don't know how. Git surely makes it easier.

2. Use git directly to work with those people, instead of working through patches.
  SVN repo remains the master so there must be developer with commit rights involved (like me).
  This would eliminate useless work fighting with diff formats etc., but also would  be an experiment of how the model works.

Linus Tornvalds explained the model in Google talks at 2007.
I will not put the link here because he also badly criticized SVN and this is a politically sensitive topic here.
For those who look at it, please ignore the SVN attack part.

Juha

[JuhaManninen]

- Don't forget side tooling like
     - Lazarus retrieving the revision for display in the IDE

This one detail is funny because currently my Lazarus About box shows the SVN revision when compiled from git repo on Linux, but not when compiled from svn repo on Windows.

I updated the latest TortoiseSVN (was it 1.7 ?). It changed the format how data is stored, and revision is not found.

On the other hand git is now well supported by the "svnrevision" code in Lazarus.
In fact most of that code now deals with git. It digs the revision from main branch even if the user works with another branch.

So things go around ...

Juha

[marcov]

I updated the latest TortoiseSVN (was it 1.7 ?). It changed the format how data is stored, and revision is not found.

On the other hand git is now well supported by the "svnrevision" code in Lazarus.
In fact most of that code now deals with git. It digs the revision from main branch even if the user works with another branch.

When installing 1.7 you afaik have to check the tickmark "commandline tools"

[marcov]

Git could really help in 2 things:

1. Manage local branches for people who want to experiment with code, and do it for more than 1 feature.
  This must be possible with SVN, too, but I honestly don't know how. Git surely makes it easier.

In SVN branching is very easy, but it is a central approach. What GIT adds is that people can maintain branches on their own local computer. (or local server).
That simplifies life for them somewhat.

2. Use git directly to work with those people, instead of working through patches.
  SVN repo remains the master so there must be developer with commit rights involved (like me).
  This would eliminate useless work fighting with diff formats etc., but also would  be an experiment of how the model works.

No, that only is when the branches are on the (main) server. For branches on 3rd party computers, it goes via patches again.

But this is not GIT specific, and was already experimented with by Florian with his mercurial mirror in, what was it, 2007?

The problem is that it is not simply "convert to git and get this one advantage", but that there must be a tremendous struggle
to keep up the current level, and conversion effort to deal with things that work differently in GIT (e.g. the missing of easy ,
sequential revision numbers, in favour of random cryptic hashes, lineendings etc etc).

For the conversion effort needed, core can probably manual edit and apply tens of thousands of patches, if not more.