On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
>> I have been looking at and working with Git for the last four or five
>> weeks and I must say that I???m very impressed by it. It???s easy to use,
> We must have different definitions of the word "easy" :)
I don?t know about your definition of ?easy? but mine matches what it says in
dictionaries. ;)
Anything subversion can do Git can do as well and most of it is simpler.
Granted, what takes a while to grasp is the concept of begin commit-based
instead of revision-based. But once you got that you _have_ to marvel at its
beauty. :)
> Here I don't agree; they are targetting a different audience, hence they
> provide a different set of functionnalities... and have different problems.
I?m not so sure about that. Sure, when Git was conceived being distributed was
a key requirement. But saying that DSCMs are only something for a small part
of all developers it wrong, IMHO. SCM is for every developer?whether it?s
distributed or not is a minor concern.
> We all agree that that merging things from branches back and forth is not
> easy with svn 1.4... but it will be easier when we will upgrade to a
> merge-tracking enabled version.
In subversion it will always be a cludge, though, because subversion wasn?t
designed with repeated merges in mind.
> What feature does it have we would *need* ?
> Since 0.7 started we had something like 6 branches...
Actually, the six branches we have are all there have been since 0.4.0 (at
least that?s the first commit in the subversion repository says). :)
But I think that having six branches is a symptom of using subversion because
heavy branching and merging is basically impossible in subversion without a
lot of manual work. We not using subversion because we don?t branch a lot but
we don?t branch a lot because we are using subversion.
I never used to branch much when I used subversion; now with Git I branch a
whole lot more. It?s easy, it keeps your construction sites apart, and
merging the branches back into some mainline branch is a breeze. With
subversion I was always very hesitant with merging branches back because I
had to keep track manually of when I merged what into where.
> First of all I am not convinced that we want to use a DSCM...
Why not? Why is a DSCM so fundamentally different? Why would it not be
appropriate for freenet? (You can still have a central repository that all
main developers keep pushing their work into and that acts as a source of
reference for other. Plus, because of all that cryptographic stuff we
wouldn?t have to host it ourselfs. If somebody messes with it, we?d notice.)
> as for the choice of GIT, well, I don't think it's appropriate in our
> usecase for the following reasons:
> - Its user interface sucks (even the git guys acknowledge that and
> that's why they developped many front-ends to git like cogito)
> - Its documentation is inexistent
As Daniel already pointed out, these points are no longer valid. A lot of work
has been done and is still being done.
> - As far as I know it's not possible to integrate it with mantis, nor
> to auto-link svn revision numbers filled into tickets to commit
> identifiers git uses.
XMMS2?s mantis[1] is somehow tied into their Git repository. For example [2]
shows that an issue was automatically resolved when the fix was committed.
> - It's a DSCM ... DSCMs concepts are more complicated to apprehend
> than SCMs concepts for the average guy; We try to lower the fence
> the average contributor has to pass in order to be able to
> contribute; not to higher it.
The average contributor is as capable to follow instructions for a Git
repository as he is capable to follow instructions for a subversion
repository. You don?t to know much about the SCM in use to create a patch.
You can even get by completely without using any SCM.
> - DSCMs encourage forking; that's definitly not something we want to
> do.
That nobody forked freenet (0.7 at least) is not a matter of the SCM we use;
it?s a matter of nobody understanding the ultra-convoluted codebase. :)
> - It's probably faster than SVN when you work locally and don't push
> your changes.
Even when pushing over the network it?s a lot faster. The transfer itself is
tiny and as the repository that does the integration is locally fast as well,
it?s faster overall. I can check out the linux Git repository in about 8
minutes and that carries the _complete_ history since 2.6.13. A clone of
freenet?s subversion repository with all commits takes several _hours_, and
it?s a lot smaller.
> Well, I was aware it was broken but didn't take the time to fix it before I
> left...
Yes, but that?s not the point. With Git, toad (or anybody else) could have
git-cherry-pick?d the three (or so) commits and applied them to trunk in a
matter of minutes. Okay, subversion can merge a revision range into another
branch as well but it will seriously barf when you try to merge the two
complete branches together later. Git would happily skip those commits as
they already have been applied. Also, it?s not the point here that toad
should have done the fix on trunk to begin with. ;)
> I'm opposed but I guess you already know it if you read that email up to
> here :)
Yeah, well, I gathered that. I still hope that Git is not completely out of
the window yet. It is a great system which I think would make our lifes at
least a bit easier.
> Florent
David
[1] http://bugs.xmms2.xmms.se/
[2] http://bugs.xmms2.xmms.se/view.php?id=1994
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20080701/6544e401/attachment.pgp>
