* David ???Bombe??? Roden <bombe at pterodactylus.net> [2008-07-01 19:23:16]:
> 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. > No, it's not a minor concern; it affects the team-work and more generally speaking the way the application is developed. > > > 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. > Could you elaborate please ? Starting with svn 1.5 each commit has both a revision number and a "merge identifier" (I'm not sure about the terminology here). Git has only one of those. > > > 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. > Blaming the tools is easy. That's also what we did regarding "why the website isn't updated" and "why aren't people reviewing commits consistently"; In both occurrences experience has shown that changing the tools didn't help. > 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. huh ? to me it's hard to make simpler than "svn cp" > 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. > That's not a concern anymore with merge-tracking as implemented in svn 1.5 > > > 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. > I recon. that I did look into it a while ago and that it may have changed :) > > > - 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. > That's exactly what we want to prevent. If the tools are too complicated people won't use them and we will end up limiting the number of "commiters"... The asset of SCMs is traceability; we want to know to who belong each single line of code we host; That might be useful in case we want to re-license the code or something. > > > - 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. > As far as I know git doesn't handle sparse checkouts. That alone is a good reason why not to use it :) I do not have a full checkout of the trunk here... and I see no point in having one; I don't buy the "it will take less space" argument. > > > 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. ;) > svn 1.5's merge tracking is solving that problem > > > 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. No one prevent you from using it; we might even consider publishing an officially converted, read-only tree... but for now, using it as our main SCM is out of question: Quote from IRC: " [13:33] <@ nextgens> | toad_> any views regarding a switch to a dscm ? [13:34] < toad_> | nextgens: broadly in favour but sceptical in the short run, we have limited time [13:34] <@ nextgens> | okay so we agree :) " Florent -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080702/d3510953/attachment.pgp>
