[Split] Locking files with bazaar/git and Qt Creator
-
[Moderator's note: split off this "older thread":/forums/viewthread/13, Volker]
Hi every one!
Until recently, I worked only on Windows and using SourceSafe and it was enough for me. Now I decided to use the Bazaar or Git, and of course with QtCreator. But I can not figure out whether it is possible to lock the files for others when I'm working with it? -
A Bazaar and Git is for working with files without locking - this tools helps with merging files. Why you want to lock files?
-
Simple answer: You can't:-)
There are different models of how to collaborate on source code: Source Safe uses the "lock mode" where only one developer can ever work at a file. That has the problem of you having to walk over to your co-worker and kick him whenever he forgets to unlock a file. Works in a co-located team, but is not a good fit for a open source project with developers distributed over the whole globe.
Git, Bazaar and most other version control systems use the "merge mode": Everybody is allowed to play everywhere. Once you publish your changes you need to merge them with whatever the other people did while you were happily hacking on the revisions you checked out before. The problem here is of course that you need to do the merging. But then you know the code (otherwise you would not be working on it, would you?), so that should be fairly easy for you:-)
In practice I tend to get surprisingly few conflicts, so there is little merging that needs to be done. Most of the time the files are unchanged to when I checked them out (you do commit often, don't you?). Even if they are not the tools most of the time do the right thing without human intervention. You do need to make sure the tools did the right thing, but you have to check what you are going to commit anyway.
-
I think sometimes it can be such that code written by different people may contradict each other.
I have to get used to this method of control :) -
I can agree to what Tobias said about merging. We are a small team, working independently on the source code, but most of the times automatic merge just works. We hardly have to resolve merge conflicts manually. Once you're used to it you never will go back to locking based versioning :)
-
I hope so. :)
-
Is there any guide or reference about using Bazaar or Git with QtCreator?
I found the following:
"http://doc.qt.nokia.com/qtcreator-2.3/creator-version-control.html":http://doc.qt.nokia.com/qtcreator-2.3/creator-version-control.htmlBut not completely understand whole process check out, check in , restore old versions etc.
-
Git (don't know bazaar too well my self) is conceptually a bit more complex than traditional centralized version control systems.
Centralized systems are rather simple: You have a server which holds the "master data". You create a local copy to work with on your machine from that (checkout). Then you change a bit there and make those changes available to your team mates by pushing them onto the server (commit).
Distributed version control systems are a bit more complex since you do not have a single server holding the master data (well, usually you have, but that is a social agreement more than a technical necessity -- "all of us will use server X for the changes we want the team to see" vs. "all our data is housed in a version control system on server X").
So what you do is you generate a copy of all the version control history on a server X (and Y and Z if you care;-) on your local machine. That is the "clone" operation. Think of that as similar to setting up a private source safe server just for yourself, containing all the code changes up to now. You then create a working directory by checking out from that local copy of the repository, resulting in a tree of source files on your disk we will call 'A'. You commit your changes into that repository, too. As long as you are inside that "private source safe server" of yours you work pretty much like before. You create changes B on top of A and commit them. Then you proceed to do a new feature, resulting in a tree of sources we will call 'C'.
Now how do you get to see what your co-workers do, living in that private world of yours?
That is where "git fetch" comes in: It fetches all the changes that were made on some other server (X) and makes them available in your private copy. Let's assume your co-worker Bob implemented another feature, changing the common base 'A' you got from the server to a state 'D'. After a git fetch you have all the following pieces of history in your local copy: A->D as well as A->B->C.
That is usually not what you want: You want something that contains your work and Bob's! At thisyou have two options:
You can merge Bobs and your changes, which will make the complete development history visible by having you merge the tree of files in state 'D' (Bobs work) and the tree of files in state 'C' (your work) into a new commit 'E' which unifies them both. You end up with one branch of your history going A->B->C->E (your work + unification) and a parallel branch A->D->E (Bobs work + unification). The history of what you did and of what Bob did is fully visible there, all the intermediary steps are there for future generations of developers to see. This is nice when e.g. you are merging a set of changes implementing a new feature back into the main work branch.
You can rebase your changes. What git rebase does is basically this: It takes the changes you did going from state 'A' to 'B' and from 'B' to 'C' and then replays them on top of a new basis, in this case 'B'. So instead of your history going A->B->C with a parallel branch A->D you end up with a history of A->D->B->C. The advantage here is that this keeps the history simple: You get one linear history (as known from e.g. Subversion, CVS and probably source safe, too, instead of changes diverging and converging all the time.
Now that you have turned your work and Bobs into one consistent piece (either by merging or rebasing) you can push this state back to the server you originally cloned from. That is done by "git push".
Does this help a bit? It is kind of git specific since that is what I use, but should be applicable to a certain degree to all distributed version control systems.
-
Tobias
Your explanation is really great.
It is more clearer now.
Seems to be using Git it's like juggling with chunks of code :)
Thanks for that!And what about practical using with QtCreator (where to click, what button press), because after some times of using, files of my project where marked with red color, and i cant understand how fix it.
-
I realized
I only need to understand all features of this menu"Screen shot":http://www.freeimagehosting.net/e0923
-
The image is not accessible.
-
Is there any image hosting which usually used for this forum?
-
Nothing special. You can use any of the free hosters. Dropbox is used by some others, for example. Google's picasa works too and I've seen some others as well, but forgot the names.
In any case, just make sure, that the image is accessible publicly for everyone. The error message "405 Not Allowed" seems caused by missing permissions for non-logged in users. I'd guess that the image is private by default at that hoster.
-
Yes this host is from my internet provider, and possible its closed for others :(
Any way i renew the upper link
"Screen shot":http://www.freeimagehosting.net/e0923 -
The menu entries reflect the usual commands of the bzr tool. I'd suggest you read one of the introductions at the "Bazaar website":http://bazaar.canonical.com/. Once you learned the usage there the menu will look familiar to you :)