Skip to main content

Home/ dvcs-vs-vcs/ Group items tagged dvcs-vs-vcs

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Daniel Jomphe

'Re: clarification on git, central repositories and commit access lists' - MARC - 0 views

lists.kde.org/?l=kde-core-devel&m=118764720327613&w=2

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • Btw, to see this in another light: as an example of a git tree that merges those same branches, but *before* they are ready, just look at the -mm tree. Now, Andrew actually ends up exposing the end result not as a git tree, but as patches, but what he actually *does* is to: - get my git tree - merge in about 30-40 other git trees from other developers (not all of which necessarily have actual development on them at any particular time) - then merge in his own patch list - expose it all as the -mm patch series So this is an example of how you actually have a totally separate, and still fairly central (the -mm tree is certainly now unknown outside of the core developer circles) tree, and where git is a big part in making a central "experimental" tree that is separate from my own central "development" tree. Also, it's an example of why centralization is bad: different people and entities have different intents. You could *not* reasonably do something like this with a centralized SCM like SVN.
Daniel Jomphe

'Re: clarification on git, central repositories and commit access lists' - MARC - 0 views

lists.kde.org/?l=kde-core-devel&m=118764715705846&w=2

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • I certainly agree that almost any project will want a "central" repository in the sense that you want to have one canonical default source base that people think of as the "primary" source base. But that should not be a *technical* distinction, it should be a *social* one, if you see what I mean.
  • Release management: you often want the central "development" repository to be totally separate from the release management tree. Yes, you approximate that with branches
  • Yes, you can branch in a truly centralized model too, but it's generally a "big issue"
  • ...20 more annotations...
  • the branches are globally visible
  • The other problem is the "permission from maintainers" thing: I have an ego the size of a small planet, but I'm not _always_ right, and in that kind of situation it would be a total disaster if everybody had to ask for my permission to create a branch to do some re-architecting work.
  • the "globally visible" part means that if you're not sure this makes sense, you're much less likely to begin a branch - even if it's cheap, it's still something that everybody else will see, and as such you can't really do "throwaway" development that way.
  • So you absolutely need *private* branches, that can becom "central" for the people involved in some re-architecting, even if they never ever show up in the "truly central" repository.
  • and you need permission from the maintainers of the centralized model too.
  • I'm literally talking about things like some people wanting to use the "stable" tree, and not my tree at all, or the vendor trees. And they are obviously *connected*, but it doesn't have to be a totally central notion at all.
  • So it's not strictly true that there is a single "central" one, even if you ignore the stable tree (or the vendor trees). There are subsystems that end up working with each other even before they hit the central tree - but you are right that most people don't even see it. Again, it's the difference between a technical limitation, and a social rule: people use multiple trees for development, but because it's easier for everybody to have one default tree, that's obviously what most people who aren't actively developing do.
  • There are lots of kernel subprojects that are used by developers - exactly so that if you report a bug against a particular driver or subsystem, the developer can tell you to test an experimental branch that may fix it.
  • The fact that anybody can create a branch without me having to know about it or care about it is a big issue to me: I think it keeps me honest. Basically, the fundamental tool we use for the kernel makes sure that if I'm not doing a good job, anybody else can show people that they do a better job, and nobody is really "inconvenienced". Compare that to some centralized model, and something like the gcc/egcs fork: the centralized model made the fork so painful that it became a huge political fight, instead of just becoming an issue of "we can do this better"!
  • This is one of the big advantages of true distribution: you can have that kind of "central" tree that does integration, but it doesn't actually have to integrate the development "as it happens". In fact, it really really shouldn't. If you look at my merges, for example, when I merge big changes from somebody else who actually maintains them in a git tree, they will have often been done much earlier, and be a series of changes, and I only merge when they are "ready". So the core/central people should generally not necessarily even do any real development at all: the tree that people see as the "one tree" is really mostly just an integration thing. When the koffice/kdelibs/whatever people decide that they are ready and stable, they can tell the integration group to pull their changes. There's obviously going to be overlap between developers/integrators (hopefully a *lot* of overlap), but it doesn't have to be that way (for example, I personally do almost *only* integration, and very little serious development).
  • Yes, you want a central build-bot and commit mailing list. But you don't necessarily want just *one* central build-bot and commit mailing list. There's absolutely no reason why everybody would be interested in some random part of the tree (say, kwin), and there's no reason why the people who really only do kwin stuff should have to listen to everybody elses work. They may well want to have their *own* build-bot and commit mailing list! So making one central one is certainly not a mistake, but making *only* a central one is. Why shouldn't the groups that do specialized work have specialized test-farms? The kernel does. The NFS stuff, for example, tends to have its own test infrastructure.
  • So we do commit mailing lists from kernel.org, but (a) that doesn't mean that everything else should be done from that central site and (b) it also doesn't mean that subprojects shouldn't do their *own* commit mailing lists. In fact, there's a "gitstat" project (which tracks the kernel, but it's designed to be available for *any* git project), and you can see an example of it in action at http://tree.celinuxforum.org/gitstat
  • So centralized is not at all always good. Quite the reverse: having distributed services allows *specialized* services, and it also allows the above kind of experimental stuff that does some (fairly simple, but maybe it will expand) data-mining on the project!
  • So I do disagree, but only in the sense that there's a big difference between "a central place that people can go to" and "ONLY ONE central place". See? Distribution doesn't mean that you cannot have central places - but it means that you can have *different* central places for different things. You'd generally have one central place for "default" things (kde.org), but other central places for more specific or specialized services! And whether it's specialized by project, or by things like the above "special statistics" kind of thing, or by usage, is another matter! For example, maybe you have kde.org as the "default central place", but then some subgroup that specializes in mobility and small-memory-footprint issues might use something like kde.mobile.org as _their_ central site, and then developers would occasionally merge stuff (hopefully both ways!)
  • different sub-parts of the kernel really do use their own trees, and their own mailing lists. You, as a KDE developer, would generally never care about it, so you only _see_ the main one.
  • You don't see how those lieutenants have their own development trees, and while the kernel is fairly modular (so the different development trees seldom have to interact with each others), they *do* interact. We've had the SCSI development tree interact with the "block layer" development tree, and all you ever see is the end result in my tree, but the fact is, the development happened entirely *outside* my tree. The networking parts, for example, merge the crypto changes, and I then merge the end result of the crypto _and_ network changes. Or take the powerpc people: they actually merge their basic architecture stuff to me, but their network driver stuff goes through Jeff Garzik - and you as a user never even realize that there was another "central" tree for network driver development, because you would never use it unless you had reported a bug to Jeff, and Jeff might have sent you a patch for it, or alternatively he might have asked if you were a git user, and if so, please pull from his 'e1000e' branch.
  • In the KDE group, for example, there really is no reason why the people who work on one particular application should ever use the same "central" repository as the people who work on another app do. You'd have a *separate* group (that probably also maintains some central part like the kdelibs stuff) that might be in charge of *integrating* it all, and that integration/core group might be seen to outsiders as the "one central repository", but to the actual application developers, that may actually be pretty secondary, and as with the kernel, they may maintain their own trees at places like ftp.linux-mips.org - and then just ask the core people to pull from them when they are reasonably ready. See? There's really no more "one central place" any more. To the casual observer, it *looks* like one central place (since casual users would always go for the core/integration tree), but the developers themselves would know better. If you wanted to develop some bleeding edge koffice stuff, you'd use *that* tree - and it might not have been merged into the core tree yet, because it might be really buggy at the moment!
  • you can use your old model if you want to. git doesn't *force* you to change. But trust me, once you start noticing how different groups can have their own experimental branches, and can ask people to test stuff that isn't ready for mainline yet, you'll see what the big deal is all about. Centralized _works_. It's just *inferior*.
  • you do a single commit in each submodule that is atomic to that *private* copy of that submodule (and nobody will ever see it on its own, since you'd not push it out), and then in the supermodule you make *another* commit that updates the supermodule to all the changes in each submodule. See? It's totally atomic.
  • Git actually does perform fairly well even for huge repositories (I fixed a few nasty problems with 100,000+ file repos just a week ago), so if you absolutely *have* to, you can consider the KDE repos to be just one single git repository, but that unquestionably will perform worse for some things (notably, "git annotate/blame" and friends). But what's probably worse, a single large repository will force everybody to always download the whole thing. That does not necessarily mean the whole *history* - git does support the notion of "shallow clones" that just download part of the history - but since git at a very fundamental level tracks the whole tree, it forces you to download the whole "width" of the tree, and you cannot say "I want just the kdelibs part".
Daniel Jomphe

Linus Torvalds: I Have Never Really Talked To Microsoft! - 0 views

www.efytimes.com/...news.htm

bsd comparison dvcs git gpl license vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • I think it is much improved over the early drafts, and I don't think it's a horrible licence. I just don't think it's the same kind of 'great' licence that the GPLv2 is.So in the absence of the GPLv2, I could see myself using the GPLv3. But since I have a better choice, why should I?That said, I try to always be pragmatic, and the fact that I think the GPLv3 is not as good a licence as the GPLv2 is not a 'black and white' question. It's a balancing act. And if there are other advantages to the GPLv3, maybe those other advantages would be big enough to tilt the balance in favour of the GPLv3.Quite frankly, I don't really see any, but if Solaris really is to be released under the GPLv3, maybe the advantage of avoiding unnecessary non-compatible licence issues could be enough of an advantage that it might be worth trying to re-license the Linux kernel under the GPLv3 too.Don't get me wrong -- I think it's unlikely. But I do want to make it clear that I'm not a licence bigot, per se. I think the GPLv2 is clearly the better licence, but licences aren't everything.After all, I use a lot of programs that are under other licences. I might not put a project I start myself under the BSD (or the X11-MIT) licence, but I think it's a great licence, and for other projects it may well be the right one.
  • I like making strong statements, because I find the discussion interesting. In other words, I actually tend to 'like' arguing. Not mindlessly, but I certainly tend to prefer the discussion a bit more heated, and not just entirely platonic.And making strong arguments occasionally ends up resulting in a very valid rebuttal, and then I'll happily say: "Oh, ok, you're right."But no, that didn't happen on SVN/CVS. I suspect a lot of people really don't much like CVS, so I didn't really even expect anybody to argue that CVS was really anything but a legacy system. And while I've gotten a few people who argued that I shouldn't have been quite so impolite against SVN (and hey, that's fair -- I'm really not a very polite person!), I don't think anybody actually argued that SVN was 'good'.SVN is, I think, a classic case of 'good enough'. It's what people are used to, and it's 'good enough' to be used fairly widely, but it's good enough in exactly the sense DOS and Windows were 'good enough'. Not great technology, just very widely available, and it works well enough for people and looks familiar enough that people use it. But very few people are 'proud' of it, or excited about it.Git, on the other hand, has some of the 'UNIX philosophy' behind it. Not that it is about UNIX, per se, but like original UNIX, it had a fundamental idea behind it. For UNIX, the underlying philosophy was/is that, "Everything is a file." For git, it's, Everything is just an object in the content-addressable database."
  • I think there's both a licence issue, and a community and personality issue. The BSD licences always encouraged forking, but also meant that if somebody gets really successful and makes a commercial fork, you cannot necessarily join back. And so even if that doesn't actually happen (and it did, in the BSD cases -- with BSDi), people can't really 'trust' each other as much.In contrast, the GPLv2 also encourages forking, but it not only encourages the branching off part, it also encourages (and 'requires') the ability to merge back again. So now you have a whole new level of trust: you 'know' that everybody involved will be bound by the licence, and won't try to take advantage of you.So I see the GPLv2 as the licence that allows people the maximum possible freedom within the requirement that you can always join back together again from either side. Nobody can stop you from taking the improvements to the source code.
  • ...2 more annotations...
  • So is the BSD licence even more 'free'? Yes. Unquestionably. But I just wouldn't want to use the BSD licence for any project I care about, because I not only want the freedom, I also want the trust so that I can always use the code that others write for my projects.So to me, the GPLv2 ends up being a wonderful balance of 'as free as you can make it', considering that I do want everybody to be able to trust so that they can always get the source code and use it.Which is why I think the GPLv3 ends up being a much less interesting licence. It's no longer about that trust about "getting the source code back"; it has degenerated into a "I wrote the code, so I should be able to control how you use it."In other words, I just think the GPLv3 is too petty and selfish. I think the GPLv2 has a great balance between 'freedom' and 'trust'. It's not as free as the BSD licences are, but it gives you peace of mind in return, and matches what I consider 'tit-for-tat': I give source code, you give me source code in return.The GPLv3 tries to control the 'use' of that source code. Now it's, "I give you my source code, so if you use it, you'd better make your devices hackable by me." See? Petty and small-minded, in my opinion.
  • I don't really believe in the 'browser OS', because I think that people will always want to do some things locally. It might be about security, or simply about privacy reasons. And while connectivity is widely available, it certainly isn't 'everywhere'. So I think the whole 'Web OS' certainly is part of the truth, but another part that people seem to dismiss is that operating systems have been around for decades, and it's really a fairly stable and well-known area of endeavour. People really shouldn't expect the OS to magically change: it's not like people were 'stupid' back in the 60s either, or even that hardware was 'that' fundamentally different back then!So don't expect a revolution. I think OSs will largely continue to do what they do, and while we'll certainly evolve, I don't think they'll change radically. What may change radically are the interfaces and the things you do on top of the OS (and certainly the hardware beneath the OS will continue to evolve too), and that's what people obviously care about.The OS? It's just that hidden thing that makes it all possible. You really shouldn't care about it, unless you find it very interesting to know what is really going on in the machine.
Olivier Valuet

ONJava.com -- Sussman on DVCS, Van Zyl using GIT+SVN - 0 views

www.oreillynet.com/...ans_on_distributed_versio.html

dvcs-vs-vcs

shared by Olivier Valuet on 30 Sep 08 - Cached
  • Olivier Valuet on 30 Sep 08
     
    Sussman cautions that the world isn't ready for wide distributed version control adoption while a few high profile open source projects move towards adopting it. Maven is trying out GIT for external collaboration, and Sun is deploying Mercurial. What do you think?
Daniel Jomphe

Setting up your Git repositories for open source projects at GitHub « Insoshi... - 0 views

blog.insoshi.com/...open-source-projects-at-github

git learning best-practices dvcs-vs-vcs

shared by Daniel Jomphe on 23 Oct 08 - Cached
  • In setting up the repositories for Insoshi, I’ve applied the version control experience I gained at Discover, where I was technical lead for the software configuration management (SCM) team.
  • Except for that interaction, everyone works within their own repository and on their own schedule. There’s no process waiting to be completed that blocks you from moving on to whatever you need/want to do next. And you’re not forcing anyone to drop what they’re doing to right now to handle your request.
  • One of the major benefits of a distributed version control system like Git is that each repository is on an equal footing; in particular, we would like every fork to have the same master branch, so that if the “official” Insoshi repository should ever be lost there would be plenty of redundant backups.
  • ...14 more annotations...
  • it’s a bad idea in general to work on the master branch; experienced Git users typically work on separate development branches and then merge those branches into master when they’re done
  • Your local repository: The “right” way Keeping the big picture in mind, here are the commands I’ve run to set up my local repository (using the GitHub id long): $ git clone git://github.com/insoshi/insoshi.git $ cd insoshi $ git branch --track edge origin/edge $ git branch long edge $ git checkout long $ git remote add long git@github.com:long/insoshi.git $ git fetch long $ git push long long:refs/heads/long $ git config branch.long.remote long $ git config branch.long.merge refs/heads/long
  • You should note that the Git URL for the clone references the official Insoshi repository and not the URL of my own fork
  • Insoshi also has an ‘edge’ branch for changes that we want to make public but may require a bit more polishing before we’d consider them production-ready (in the past this has included migrating to Rails 2.1 and Sphinx/Ultrasphinx).  Our typical development lifecycle looks something like development -> edge -> master
  • I’m resisting the temptation to immediately start working on the local ‘master’ and ‘edge’ branches. I want to keep those in sync with the official Insoshi repository. I’ll keep my changes separate by creating a new branch ‘long’ that’s based off edge and checking it out
  • I’m starting my changes off of ‘edge’ since that contains all the latest updates and any contribution I submit a pull request for will be merged first into the official Insoshi ‘edge’ branch to allow for public testing before it’s merged into the ‘master’.
  • I’m finally adding the remote reference to my fork on GitHub
  • We should run a fetch immediately in order to sync up the local repository with the fork
  • I’m pushing up my new local branch up to my fork. Since it’ll be a new branch on the remote end, I need to fully specify the remote refspec
  • Now that the new branch is up on my fork, I want to set the branch configuration to track it
  • Setting the remote lets me just simply use $ git push to push changes on my development branch up to my fork
  • I’ve got a shell script for you.
  • The extra work is worth the effort, because with this configuration My changes will be easily identifiable in my named branch I can easily get updates from the main Insoshi repository Any updates I’ve pulled into master and edge are automatically pushed up to my fork on GitHub The last one is a bonus because the default refspec for remotes is refs/heads/*:refs/heads/*. This means that the simple ‘git push’ command will push up changes for all local branches that have a matching branch on the remote. And if I make it a point to pull in updates to my local master and edge but not work directly on them, my fork will match up with the official repository.
  • So what is the benefit of all this to open source projects like Insoshi? The easier it is for the contributor to pull in updates, the more likely it will be that the pull request will be for code that merges easily with the latest releases (with few conflicts) You can tell if someone is pulling updates by looking at their master and edge branches and seeing if they match up with the latest branches on the main repository By getting contributors in the habit of working on branches, you’re going to get better organized code contributions Basically, the less effort that’s required to bring in code via a pull request, the sooner it can be added to the project release. And at the end of the day, that’s really what it’s all about.
‹ Previous 21 - 29 of 29
Showing 20▼ items per page