[Kde-scm-interest] KDE trunk imported into Git

[Max Hofer]

Hi all,



just stumbled over the list and thought i share my two cents about 

shared SCM systems.



I evaluated git, bazaar and hg for use in our enterprise (a half year ago)

and we reached the conclusion to use mercurial.



Main reasons for this choice (at this time):

- it was fast enough for the volume which we use (approx. 200 MB/project)

- it works on different OS (tested on linux, windows and solaris)



We dropped Bazaar because it was too slow at this time (but I heared this improved

in the last months).



We dropped git because it was essential that ppl could use it on different operating

systems (git was poorly performing on Windows).



A good summary (which confirms my impression) can be found at:

http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/



From the point of view of (command line) UI it does not matter which one is picked.

As soon developers grasp the conecpt of distributed SCM systems all of those systems

are quite easly to learn (i needed about a half day to get used to the most

common commands).



After we switched from svn/cvs to hg I never digged deeper into git, nor into

bazaar.



Now to your questions below.



>Apparently Mercurial comes with a nifty tool that allows us to convert from 

>Git to Mercurial.

>

>So I ran:

>$ hg convert git3/KDE/kdelibs hg/kdelibs



I never used convert (because it did not exits at the time when we ported svn/cvs

projects into our git repository). But i think it would be a better idea to convert

the subversion repository directly into the hg (svn --> hg) instead making a detour

over git (svn --> git --> hg).



>However, hg seems to have a weird notion of branches:

>$ hg branches

>default                        74638:9cd90cab9ac2

Could you explain  "weired"?  

The output above just tells you: we have a repository with one branch which is 

called default. In Mercurial each repository has one default branch called "default" 
- it is like the trunk in svn/cvs.

The two numbers are the Revision Id and the change set ID (In Mercurial, 
RevisionNumbers describe the history of an entire Repository.  Furthermore, in 
Mercurial, a RevisionNumber is local to a repository.  To uniquely identify a 
ChangeSet, the changest iD is used) ---> your convert operation created 74638
commits.

So if you speak with other developers you usually refere to changeset IDs because
the revision numbers are local to your repository and do not exits outside of it.

Maybe it helps if we go in more detail definining what a branch is. From 

http://www.selenic.com/mercurial/wiki/index.cgi/CvsConcepts#head-747fb4482ddcc2cf3575896c226b4aa8ea07c19b



"In Mercurial, a branch is a repository.  Nothing more or less.  A repository is a branch.  
Repeat the soothing mantra. The verb "to branch" simply means "to make a clone of 
a repository at a particular revision"."

If every repository is a branch, how do you keep track of which one is which?  That's 
simply a matter of convention..  Mercurial has no idea which Repository is the "trunk", 
or which is a "branch"; it's all a matter of how you use the repositories."



The concept of branches used by svn/cvs is called in Mercurial "named branches" 
which means you can create a branch in a repository 
(see http://hgbook.red-bean.com/hgbookch8.html#x12-1650008.5).

The choice when to use named branches or a repository for a branch is uppon 
you (there are some advantages and disadvantages choosing one above the other). 
To keep it easy: named branches are less expensive in terms of disk storage. But 
using repositories as branches may help you with speacial extensions (like preventing
to merge from certain branches etc. --- 
see extensions http://hgbook.red-bean.com/hgbookch14.html#x18-31600014).

Hypothetical Example: KDE 4.0 is a repositroy and each bugfix releases (4.0.x) are named branches. The KDE 4.1
branch is an own repository, etc.
>$ hg log -r .
>changeset:   73049:954ea2f61d88
>user:        Fredrik Höglund <fredrik at kde.org>
>date:        Thu Dec 27 20:31:03 2007 +0000
>summary:     Implement support for repeat-x, repeat-y and no-repeat in 
>CanvasPatternImpl.
>
>Which matches the tip of refs/heads/master in the Git repository, including 
>the broken encoding of the committer's name.

Maybe hg would deal correctly with the broken encoding if you would convert
it directly from the subversion repository - try it.

Since i never played with the convert tool I think you should ask for help
on the mercurial mailing list. They are very helpful 
(http://www.selenic.com/mailman/listinfo/mercurial/).

Since bazaar, git and mercurial seem to handle source code fast enough you
should focus on the features your DSCM should (special to KDE) have. 

Appart from having an easy merge operation the biggest advantage of using
DSCM is how the interaction between the developers change, i.e. the social
interaction (who can commit, who pulls from whom, who decides what is going
into the release, who accepts patches,how are patches delievered ...)

What comes in mind to me is:
- parallel development in subversion and <DSCM> until all developers
switched. This means it should be relative easy to pull changes from
the svn to the <DSCM> and vice versa without loosing anything (code,
commit info, prevention of double merges etc.)
- managing repositories in a tree like structure (kdelibs, kdepim, ...
are different repos, with dependencies). Mercurial has an extension called
forest which deals with this kind of feature.
- how are patches integrated into the repository (patches via mailing lists)?
Who decides if a patch goes into the repo? Who is the authoritive person for
which module?
- graphical UI to the DSCM
- functional branches: i.e. a branch with new feature code (be aware this is
more selecetively than using one single branch with new features. Like having
branch-4.1.0-feature-X, branch-4.1.0-feature-Y, branch-4.1.0-feature-Z which are
all kept separately from the branch-4.1.0 until they are ready to be included).
- what features does the DSCM have for the automated test environment (nightly 
builds, etc.)?

In my opinion one of the biggest advantages of KDE 4.X over 3.x is the possibility
to run it on Windows and Macs. This means also new developers may join the
KDE project which were previously not reachable. So keep in mind that the DSCM you
want to use should be available on the different OS.

I hope this helps to clarify some questions you had.

kind regards

Max













      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail