a question about developing moodle under SVN environment

a question about developing moodle under SVN environment

by Murad Jamal -
Number of replies: 26

dear all,

we are three developers (have one server and 3 laptops), we customize moodle accodring to our needs, but we did not use SVN untill yesterday. we have installed SVN binaries and TortoiseSVN client, and configured apache to link it with our SVN for authentication, everything works fine. Then we imported our original moodle copy into the repository, and every developer checked out his own working copy from the server and put it on his own machine to start working, in this case two problems came up:

1) there would be a config.php file for each checked out copy, the config file refers to a data folder (i.e. moodle data folder) and that would be the same for each checked out copy (the data folder resides on the server where the original moodle copy resides), the line is : $CFG->dataroot  = 'D:\mylmscontent';

each developer would work on his own local copy and of course test it (locally) with each step he makes a change, but how would that be done without a data root folder resides on his own machine ? if we supposed he created a new folder on his machine (c:\my_content) and pointed the above line to it ($CFG->dataroot  = 'c:\my_content';), I think that would be incorrect because when he (at the end of the day) comits his wokring copy to the repository, the config.php file on the repo would change according to that developer's data root folder path.

2) the database would face the same issue, each copy for each developer must connect to the DB specified in the config.php file, should each developer have to have a local DB on his machine with same name and credentials specified in config.php file?

thank you so much in advance!

Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Murad Jamal -
in brief, how to set up a moodle SVN development environment (server: windows 2003, developers machines: windows 7) ?
Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Murad,

Moodle currently supports CVS for development and this is mirrored to Git. My guess is that Git will become the primary development environment in the fullness of time.

Subversion doesn't even feature, so you'd be going out on your own somewhat. I would strongly encourage you to look at Git. There is a lot of experience and enthusiasm here to help.

Start here.... Tracking_Moodle_CVS_with_git
Average of ratings: Useful (1)
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Hubert Chathi -
The easy answer to your question is: don't put config.php under version control, since it should be different for each checked-out copy.

SVN should have a file (possibly called .svnignore? It's been a while since I've used SVN) that lets you list files that it should ignore.

But since you are just starting with SVN, I would echo Howard's note, and encourage you to look at git instead. Moodle is planning on switching to git (when the tools are more mature). Being a decentralized version control system, it may have a bit of a steeper learning curve, if all you're used to is CVS or SVN, but the advantages are worth it, and there is quite a bit of good documentation.
Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Frank Ralf -
Hi Murad,

You might have a look at Development Environment for Drupal for detailed instructions on how to set up a development/staging environment using SVN.

But you really might be better of in the long run with hooking into git wink

hth
Frank
Average of ratings: -
In reply to Frank Ralf

Re: a question about developing moodle under SVN environment

by Murad Jamal -

thank you guys for your advice about CVS and GIT, I used this link (which you provided above) :

http://docs.moodle.org/en/Tracking_Moodle_CVS_with_git

and started to read for around 5 hours of continuous reading, I installed a lot of components (GIT, PuTTY, TortoiseCVS, CVS Suite etc ...)

and now I'm so lost sad

because of these reasons:

1) after a lot of reading and research, i couldn't find what is the relationship between CVS and GIT !!

2) why do I need CVS, I already have SVN running smoothly (except for the above two problems which I mentioned) and it's very easy to implement, why should I get into GIT complexities ...

3) CVS will not magically solve the above two problems for me. I didn't notice a difference. plus resources about it are scattered here and there.

so I got completely LOST sad

Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You don't need CVS to manage your own customisations.

You just need git. The advice to use git for your own customisations, instead of SVN, is good advice.

But you can use SVN if you want - you are just less likely to find people here who know enough to help you.


The answer to your question is the same whichever version control system you use, and it has already been given above:

1. config.php should not be in version control. Each developer should have their own local config.php file.

2. Each developer should have their own database to use for development. The information for connecting to that database is what should be in each developer's config.php file.
Average of ratings: -
In reply to Tim Hunt

Re: a question about developing moodle under SVN environment

by Murad Jamal -

I couldn't, up to this moment, figure out any advantage for git over regular SVN ..

about the answer that Mr. Tim Hunt provided :

1) config.php file issue can be solved by ignoring it from version control

2) it's not reasonable to pull a whole database (which is in our case an oracle DB) which has a lot of users and data, and put it on localhost !! we need DB data while developing, and the DB is too big to put on localhost.

I tried to connect to that DB but without success, I started a thread about this problem here.

Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
2) I would not recommend using a copy of your whole live database for development.

You do need a copy of your whole live system for use when testing upgrades, before you make them live.

But for development, each developer should have their own database, where they can set up small amounts of test data to test rapidly, but where the also have the freedom to wipe the whole thing and start again when they screw something up.

The development database can either be on localhost, or can be on a server somewhere. (At the OU, we all have our own private development database, but on a server that is configured to be similar to our live environment.)

I my development database, I have about 5 different Moodle installs with different settings for $CFG->prefix, so I can test standard Moodle 1.9 and HEAD, and also various OU versions.
Average of ratings: -
In reply to Murad Jamal

Why git is better than subversion or CVS

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The real point about git (or Mercurial, DARCS, Bazaar, ...) is that they are distributed version control systems.

With CVS or Subversion, the underlying assumption is that there is one central server that tracks all the versions.

In your situation, that is not true. There is one central CVS server, cvs.moodle.org, which has the master version of the code.

Then you want to do local customisations, which you want to store somewhere like mysvn.example.com.

Now, there are tools and scripts out there which let you connect everything together and make it work, but they are clunky.


Git, and other distributed version control systems, are designed for exactly this situation. There is git.moodle.org (which is a read-only copy of cvs.moodle.org).

If I like I can 'clone' that, and set up my own private copy like http://github.com/timhunt/Moodle-Question-Engine-2. In there, I get a copy of all the official Moodle version history, but I can also track my own changes.

Then I can clone that onto my my desktop computer, so I can work there, and onto my laptop, so I can work there.

To move changes between one place and another, I use the commands git push and git pull.

To combine official changes from git.moodle.org with my local changes, I can use comands like git merge and git rebase. These work much better than cvs or snv merge, in my experience. I think that is because they can access the whole version history to help resolve conflicts.

And, as an added bonus, git in incredibly fast. It is hard to find a command that takes more than a second to run.


But, as I think I said above, it is a bit a learning curve to get up if your are familiar with CVS or Subversion. Also, git is newer, so you don't have nice integrations into IDEs like Eclipse yet. I think it is definitely worth the effort to learn, but you have to make your own judgement.
Average of ratings: -
In reply to Tim Hunt

Re: Why git is better than subversion or CVS

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Git is nice but there are some pitfalls we have to avoid, such as:

Forking - it is much easier to fork Moodle main codebase and introduce design changes that are going to be impossible to upgrade in future, main DB changes are still crazy, no matter what version control system you are going to use.

Lack of centralisation - at present I may simply checkout the who contrib and easily grep for usage of individual functions, look for common security issues, etc. This is extremely valuable when refactoring stuff in HEAD. It is easy to keep your modifications hidden inside your local network, everything should be publish somewhere available for everybody and easy to find.

Ignoring of admins/developers that do not use command line tools - git is the least IDE-friendly versioning system I ever used, sorry.

Blind merging - git is much better at merging than cvs, but no automated tool may actually replace the human there. Developers sometimes forget to review the results and test code after merging.

Petr
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Martín Langhoff -
Yes, you have to be careful with DSCMs.

On the forking side, yes, developers need to be mindful, and the DB changes need to move from a linear model to a "patches" model. And blind merging is a mess, and developers need to check and test the results... but that happens on any SCM (with CVS and SVN you get it with the merge that happens on un-committed changes).

For the lack of centralisation for something like contrib you can have a hosting site for those contrib modules (git.moodle.org wink ) plus a "meta-project" using git-submodules. Then you clone/checkout the "moodle-all-contribs" meta-project and you get the equivalent of a cvs checkout of the "top" of contrib.
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Frank Ralf -
"git is the least IDE-friendly versioning system I ever used"

I can second that. I tried TortoiseGit the other day and it totally ruined my Win 2000 system (TortoiseCVS and TortoiseSVN among others) sad
Average of ratings: -
In reply to Frank Ralf

Re: Why git is better than subversion or CVS

by Martín Langhoff -
I can't talk about TortoiseGit, except to say: make sure you tell the developers (nicely if possible) about your adventures. Hopefully it's a fixable bug.

From traffic on the git list, git-cheetah seems to be popular with Windows users. Might be worth a try.

I am an SCM power user, and was never impressed with _any_ of the GUIs available for CVS or SVN (over 12+ years of use, I tried a few wink ). They always messed up some files, showed incorrect data, and took ages to do anything (that last part we can blame on the CVS/SVN backends).

It's hard to make a good GUI for an SCM. I've settled (as a user) into the idea that some SCM things a GUI is good, for others you *really* want a commandline with tab-completion. There are just too many useful commands -- won't fit in a toolbar, or in a manageable menu.

So that's how I use git -- commandline with tab-completion + gitk for GUI-powered history browsing.

Never been happier.
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Dan Poltawski -

Forking - it is much easier to fork Moodle main codebase and introduce design changes that are going to be impossible to upgrade in future, main DB changes are still crazy, no matter what version control system you are going to use.


For non-core developers this is massive selling point. As a non-core developer you might need to fork if core is too busy to accept your brilliant patch which brings world peace (vim as default editor).

Or indeed for core developers like myself its also a selling point - I have some crazy features that will never be accepted into Moodle core and I can manage the changes relatively easily with git. Or even if I do manage to add them to Moodle core I can also track them in 1.9 (where they would not be accepted into the stable branch).

This is a selling point, not a pitfall. If people want to fork moodle they can do this anyway irrespective of VCS.
Average of ratings: -
In reply to Dan Poltawski

Re: Why git is better than subversion or CVS

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
I do not agree, your examples are not forks, those are just local nodifications.

Fork is something like completely changing APIs, changing core db structure - it breaks after next major upgrade completely and sometimes is not even fixable, very often other contrib plugins do not work in forks.
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Martín Langhoff -
If you fork in the way you describe (change APIs, change db structure) you can't merge usefully. The SCM has nothing to do with it -- it is a strategic & technical decision.

When you talk about "forking" within this discussion of SCMs and wanting to keep the code harmonious and mergable, my understanding is that you were meaning something like "branching to make significant changes, attempting to keep compat, with no intention of forking".

To fork is a strategic, often social/political decision -- see gcc/egs and emacs/xemacs for the main examples. One merged, the other one stayed forked foreverz.
Average of ratings: -
In reply to Martín Langhoff

Re: Why git is better than subversion or CVS

by Dan Poltawski -
Just read an interesting article from joel on software which touches on many of these points:

“To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

...

With distributed version control, the distributed part is actually not the most interesting part.
The interesting part is that these systems think in terms of changes, not in terms of versions

....

If you come at Mercurial with a Subversion mindset, things will almost work, but when they don’t, you’ll be confused, unhappy, and unsuccessful, and you’ll hate Mercurial."

...

When you manage changes instead of managing versions, merging works better, and therefore, you can branch any time your organizational goals require it, because merging back will be a piece of cake.


(but actually read the whole article..)
Average of ratings: -
In reply to Dan Poltawski

Re: Why git is better than subversion or CVS

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Thanks for linking to that Dan. My favourite quote was:

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

which got a LOL.
Average of ratings: Useful (1)
In reply to Martín Langhoff

Re: Why git is better than subversion or CVS

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
My point was that if your SCM allows you to merge easier then you may feel inclined to do more changes in your local "fork" (or whatever you call it). Your CMS may enable you to share your stuff with others really easy, but then they start depending on your fork. The question is: are you going to maintain it forever? Is there a way back to vanilla install?

With CVS we did not have such problems because it is lame and it was a pain to maintain any modifications. In case of git it is easy to do this but with freedom comes much bigger responsibility.
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Iñaki Arenaza -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

So the question I would ask is: why do others want to depend on my fork? Or even, why do I want to make a fork in the first place and maintain it myself?

And the only answer that I can think of is: because the fork it's useful and that usefulness can't be found in the mainstream version.

If the tool allows me to maintain that fork in an easier way, then why not use it? (remember I was interested in the 'forked' functionnality in the first place, no matter which tool I would need to maintain it).

That the DSCM makes it easier for others to actually use my fork means that is also makes it easier for core developers to pick my fork changes and merge them back in the mainstream version when they think the changes are worth it. And even if they don't merge them verbatim, the DSCM is going to help me merge them locally when I get them from mainstream in the future.

Regarding the question: "are you going to maintain it forever?", I think it doesn't really matter a lot. If I do, people can continue basing their work on my DSCM repository. If I don't, even if I completely delete my repository (or deny access to other people) you have a full copy of my fork in your own DSCM repository. So you loose "nothing".

As to whether there is a way back to vanilla install, as soon as you start making certain kind of changes (no matter if you use a DSCM, a CSCM or you simply edit your files by hand), there's no way back. But as Martin Langhoff has said, this has little to do with the tools and a lot to do with strategic/technical decisions.

By the way, the fact that the tools (CVS in this particular case) make forking the project a bit harder doesn't make the need/decision go away smile

To summarize, I'd say everybody benefits from the tool (pick whichever DSCM you like most smile) and the development model.

Saludos, Iñaki.

Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVSmore

by Dave Balch -
It seems to me that the issues involved in maintaining a fork are separate from the (dis)advantages of any particular SCM.

As Git supports easier branching and merging than CVS & SVN, that makes it more powerful - but if the work maintaining a branch or fork is too much, don't use the feature (and don't make any major changes to Moodle).

I use Git, without using branches a lot - but I have a feeling that, once I'm more comfortable with how Git handles them, I'll be able to manage my changes a lot more effectively...
Average of ratings: -
In reply to Petr Skoda

Re: Why git is better than subversion or CVS

by Dan Poltawski -

Lack of centralisation - at present I may simply checkout the who contrib and easily grep for usage of individual functions, look for common security issues, etc. This is extremely valuable when refactoring stuff in HEAD. It is easy to keep your modifications hidden inside your local network, everything should be publish somewhere available for everybody and easy to find.


The only way to solve this problem is to embrace DVCS and provide facilities to allow 'contrib' modifications to be easily hosted and reviewed in one place. e.g. by providing a contrib. mercurial hosting service or place to publish repositories.

In fact I would strongly argue that centralised VCS make it harder to publish your custom code to review because you need to go through 'a gatekeper' to get access to the CVS. Ok I could setup my own cvs server, but how do core developers compare my branch with their own (answer: with great pain). This is where DVCS shine. I can easily add a remote to do this, and in fact I already do this, core moodle, my employers moodle contributions, my personal stuff, eloys backup branch, tims quiz rewrite and the paintweb repo.

Some people avoid the centralised model (look at the number of third party modules which aren't in cvs) and we can't stop them. DVCS facilitate this collaboration, if we don't provide tools to help centralisation it will become decentralised because there is no way to stop dvcs from spreading anyway.
Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Hi,

On reflection that probably wasn't the best link to send you to.

All you need is to pull your data from Moodle's git repository and work with that. Forget about CVS.

Git is very nice to use once you have un-learned the SVN and CVS way of doing this. This is actually the difficult bit.
Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Murad Jamal -

thank you guys for your kind replys, however, I really didn't start this thread to compare SVN with Git or with CVS, I just wanted to know how to manage moodle code among a number of developers with any easy method. 

your comments were very hard for me to understand sad forking, blind merging, etc ... and many other advanced terms ...

what's all these complixeties ???

@ Tim Hunt:

" The real point about git (or Mercurial, DARCS, Bazaar, ...) is that they are distributed version control systems.

With CVS or Subversion, the underlying assumption is that there is one central server that tracks all the versions.

In your situation, that is not true. There is one central CVS server, cvs.moodle.org, which has the master version of the code.

Then you want to do local customisations, which you want to store somewhere like mysvn.example.com.

Now, there are tools and scripts out there which let you connect everything together and make it work, but they are clunky "

can you explain how git is a distributed system ? do you mean that the master version of the code (head) can be hosted on, let's say, gitHub and unfuddle, etc ... or do you mean that every developer pulls his/her own copy of Head version of code and starts a new branch, add their code, and finally merge their work with head ?

if you meant the second thing, then, SVN can do so easily ..

and why should I use services like GitHub to store my code ? I can simply use my own repository which I create on our sever in the company ...

i didn't understand exactly how it can be distributed !

what's the difference between when you clone and pull a copy of code in terms in Git ?

 " To combine official changes from git.moodle.org with my local changes, I can use comands like git merge and git rebase. These work much better than cvs or snv merge, in my experience. I think that is because they can access the whole version history to help resolve conflicts.
 "

SVN has the same capability, it can access every bit of history to investigate any issue that may result.

 still kinda mssed up sad with a pile of complicated posts here ...

 

Average of ratings: -
In reply to Murad Jamal

Re: a question about developing moodle under SVN environment

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well, I could try to explain what distributed version control is all about, but Joel Spolsky has already done a better job than I could do: http://hginit.com/ (That link came from the article Dan linked to above.) For the purposes of what you are asking about, git and Mercurial are essentially identical.


Apologies that this thread turned into a bit of a holy war. But some things have that tendency. You might as well ask, "Which is better, vim or Emacs?" wink
Average of ratings: Useful (1)