User forums => General (but related to Code::Blocks) => Topic started by: irf610 on June 21, 2006, 03:41:34 pm

Title: Codeblock project and SVN repos.
Post by: irf610 on June 21, 2006, 03:41:34 pm
I'm setting up an svn server for the first time(yeah!) and I am not sure what to do about the codeblock project file. As I see in the Code::Block repository there is a CB project file availble. I wonder how this file is shared between different developers.

Also the gui design section. The software gui's is done in DialogBlock. Should the project file be availble in the reopsitory also and how multiple people are going to use it...

Any comments on the subject?

Jonathan Blanchard
Title: Re: Codeblock project and SVN repos.
Post by: thomas on June 21, 2006, 04:07:53 pm
Both should be in the repository. Version control with Subversion works by allowing everybody to modify sources and merge them later. This works surprisingly well most of the time. Yes I know you cannot imagine it could ever work, but it does ;)

Merging files works well on text documents (including XML), but often fails on binary data, images, and the like.

The Code::Blocks project files are XML files, so they are easily mergeable.

I cannot tell you about DialogBlocks, but I guess they use XRC anyway which is XML too (when in doubt, just open it in a text editor, and you'll see).

For binary files, you should either have good inter-developer communication (you should have that in any case!) or you should set the svn:needs-lock property on those files. This property will cause the checked out files to be write protected. To modify them, you have to acquire a lock first. Only one person at a time gets a lock on a file.

Of course you can still actively cheat around locks (you can always remove the read-only flag, and you can force locks, too), but that's not what they were made for. Locks are meant to prevent accidential collisions, and they work very well for that purpose. They do not prevent active cheaters.

The most important thing is communication, though (did I mention that?) ;)
Title: Re: Codeblock project and SVN repos.
Post by: irf610 on June 21, 2006, 05:48:44 pm
So you mean that everybody get the latest code::blocks project file and they then commit this same file and it work without problem?

That is kind of impressive...

thank you very much for your reply
Title: Re: Codeblock project and SVN repos.
Post by: thomas on June 21, 2006, 06:39:13 pm
You add the project file to the repository once.
Then any number of people can check out a copy of it.

Most of them will not need to modify that copy, so they obviously don't commit the file over and over again.
However, if for example someone adds a file to the project (or changes compiler options, or whatever), then he would commit the project file afterwards. That will upload the changes made to the repository. The other users will see those changes when they next update.
This was the simple case (one person making modifications, several reading).

Now, what happens if two developers make changes to the project file at the same time and commit? Very likely, the changes will not be in exactly the same line, so Subversion will merge those changes automatically. To ensure that this works reliably, Subversion checks whether your revision is the same as the one in the repository and possibly requires you to update before letting you commit. During that update, the changes made by other people are merged to your working copy, which you can then commit.
Someone who updates after this will see the changes made by both developers.

Finally, what happens if two people happen to change the same line in the same file at the same time?
In this case, the changes cannot be merged automatically (since Subversion does not know what to do). If this ever happens, you will get a message about a "conflict" when you update. You can then resolve that conflict using a tool like for example TortoiseMerge, it is usually quite painless. After that, you commit, and all is good.

The only thing that is really ever a problem is binary data. For these, it is best to use locks and to communicate before changing them.