Marcel Siegert wrote: > > i do know mercurial and that one sucks. Hey :-(
> on linuxtv.org each modification (to prevent too much conflicts) > should be in a seperate repository. Preventing conflicts is not the point. IMHO it is quite natural to do seperate lines of development in seperate branches. So that they can be reviewed and integrated into mainline seperately. The git way is to use "topic branches" within one repository, but the mercurial way (one branch per repository clone) is IMHO both simpler to use and more visible to others. > so you have to have one repo e.g. where you develop new things, > one for clean to pull from, and > if like you have, loads of repos must be pulled, merged, ect. > imho that is much more work. That sounds like "hg doesn't behave like cvs, thus I hate it". When I evaluated potential CVS successors for linuxtv.org (among them svn, svk, git, monotone, codeville, tla/arch) I finally settled with mercurial for mainly two reasons: 1. it's fast 2. it's dead simple to use Consider: Let's look at cvs first. If you check out from a cvs repository and start making changes, you _conceptually_ already created your own, private _branch_. Think what happens if someone else commits to the repository where you checked out from -- you have changes based e.g. on Rev 1.23, while the repository is maybe already at Rev 1.26. Now when the time comes for you to commit your changes, you _conceptually_ need to _merge_ the upstream changes first with your edits, by running cvs update. cvs here cheats in two ways: 1. It doesn't record the fact that there was a merge and that your changes were really based on Rev 1.23 -- the cvs history will look like you checked out Rev 1.26, made a change, and comitted Rev 1.27. 2. cvs works _file based_ -- if you make changes to foo.c while someone else meanwhile comitted changes to bar.c, cvs doesn't care at all and lets you commit without merging. This can lead to build breakage, so it's good practice to always run "cvs update" before "cvs commit", but cvs does not enforce this. Now a DVCS (git, mercurial or whatever) basically changes this behaviour in the following ways: 1. you can commit to you local repository clone, thus the history records exactly what happened 2. DVCSs work _on the whole repository_ -- if you make changes to foo.c while someone else changes bar.c, those changes are on seperate branches and you have to merge _explicitly_. This is what Marcel is complaining about -- but apart from running "hg merge; hg commit" there is no additional work to be done. Again the history just records what actually happened. If many developers try to push changes to a central repository, I believe that the many explicit merges would get in the way. Usually this is handled by restricting the number of developers who can push to the main repository, and have one or a few maintainers collect changes from developers (e.g. only Linus himself pushes to the main kernel git tree). On the plus side, DVCSs give you - local commits - private work can easily track mainline (pull & merge), and can later be published - easy sharing of local work (with mercurial you can send patches or bundles per email, or just run "hg serve" and tell your buddies on irc to pull from http://123.45.67.78:8000/) - easy to create and discard branches/clones for experimental work - better patches because people don't hack away forever and then have to type "cvs diff" at the end to send of all in one hunk HTH, Johannes _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
