Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Canonical releases Version 1.0 of 'Bazaar' version control tool (Linux-Watch)
Linux-Watch covers the
release of Bazaar 1.0, a distributed version control system in Launchpad. "In a Linux-Watch
interview, Shuttleworth explained that by making it easier to work in
independent branches, which can then be easily adopted into the main code
tree, Bazaar encourages developers to explore new ideas within a project
rather than forking their new idea into another, related open-source
project. This, in turn, "lets new developers start contributing immediately
and working on new ideas even when they can't get buy-in with old guard."
Thus, "this discourages forks and helps with the social conflicts between
new and older project developers. It makes it easier for people to learn,
work and have fun together on a project.""
(Log in to post comments)
One of many free distributed version-control systems Posted Dec 14, 2007 21:01 UTC (Fri) by stevenj (guest, #421) [Link] It was a bit surprising that the article mentioned the old-style CVS and Subversion, but not any of the many other competing distributed version-control systems (VCSs), such as:
Because of its use in the Linux kernel and some other prominent projects, git seems to be getting the most attention and may well be the long-term winner. For now, however, my personal favorite is still darcs — it is a bit too slow for kernel-scale projects, but for smaller projects I find it plenty fast and its interface to be much simpler and more coherent than git's, and it is designed from the beginning for cherry-picking patches (instead of this being a hacked-on afterthought as with the current git). This makes it easy, for example, to merge my repository with one of three patches from your repository with two of four patches from someone else's repository, maintaining correct patch dependencies and reversibility. Fortunately, there are conversion tools between most of these, as you might expect with FLOSS projects, so you aren't locked into one choice. (Although it is still a bit dismaying how much duplication there is...do we really need this many?)
Re: One of many free distributed version-control systems Posted Dec 14, 2007 21:47 UTC (Fri) by larryr (guest, #4030) [Link] Yeah, the article was pretty content-free. To me, git and bzr are the main competitors among systems with a modern design. The bzr site has a list of features and a comparison with git. Perusing the bzr documentation quickly, I did not find much information describing a file structure as the foundation, and it seems like maybe bzr is more based on and focused around operations/behavior rather than underlying structure. What I liked about git from the beginning was the foundation of an almost trivial underlying structure for state information storage, and everything else (behavior) was built on that. Larry@Riedel.org
Re: One of many free distributed version-control systems Posted Dec 14, 2007 23:08 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] take the comparison with a gain of salt. remember that it was written by people who understand bazaar extremely well, but may not understand git quite as well and when you start making arguments about which is 'easier' you are really talking opinion as much as anything else ;-) all of this isn't helped by the rapid pace of development of both projects.
Re: One of many free distributed version-control systems Posted Dec 15, 2007 17:48 UTC (Sat) by stevenj (guest, #421) [Link] and when you start making arguments about which is 'easier' you are really talking opinion as much as anything else ;-) Ease of use is partly a matter of taste, of course. The real problem, however, is that most of the arguments about ease of use are made by people who have only used one system extensively and their opinions are heavily influenced by familiarity. Nevertheless, interface design is a tremendously important issue, and it is possible to do objective usability studies. At the very least, I would love to a serious comparative review of the various distributed VCS systems by a group of people who force themselves to use each one for a week or two of real work, to give them a chance to get familiar.
Re: One of many free distributed version-control systems Posted Dec 15, 2007 21:11 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] the problem with your suggestion is that with a distributed system there are many workflows, and some workflows are supported easier then others for a particular system. as a result it's not as easy as saying 'use it for a week or so and pick a winner' it is also not always obvious how well a particular tool will support a particular workflow. I know the git mailing list gets a question of ;can git support this workflow' few weeks. useually there's an immediate answer, sometimes it's a workflow that the git developers had never considered before, and in these these cases it's sometimes a case of useing existing commands in different ways, but once in a while changes are neeeded to support it. and sometimes features of a distributed system just make it impossible to do some workflows. for example, the bazaar version numbers don't work in a multi-master workflow, but the bazaar people feel that in a more centralized workflow they simplify things enough that they list them as an advantage over git, where the git people would list them as a disadvantage for bazaar
Re: One of many free distributed version-control systems Posted Dec 16, 2007 19:40 UTC (Sun) by jwb (guest, #15467) [Link] I agree completely. I feel that each of the major systems has a native workflow, and if you get very far from that workflow, you will feel burdened and uncomfortable. The reason I don't use git is because I never send or recieve patches by mail or as patch files of any kind, but this is the central idea of git. I prefer to push and pull via ssh to the trees and branches of my colleagues because all of us use the same machines for development. I find that mercurial's pull/merge/update cycle makes sense and that git's native workflow makes little sense.
Re: One of many free distributed version-control systems Posted Dec 16, 2007 20:36 UTC (Sun) by sobdk (guest, #38278) [Link] The reason I don't use git is because I never send or recieve patches by mail or as patch files of any kind, but this is the central idea of git. I prefer to push and pull via ssh to the trees and branches of my colleagues because all of us use the same machines for development. I'm sorry but that is the silliest thing I have ever read. The reason you don't use git is because you obviously never bothered to learn how to use git, or the work flows that it supports. That is fine by me, use whatever tools you prefer, but please don't claim git doesn't support push and pull via ssh.
Re: One of many free distributed version-control systems Posted Dec 16, 2007 21:39 UTC (Sun) by jwb (guest, #15467) [Link] You're not sorry, because right after you said "I'm sorry" you then proceeded to insult me anyway. I'm sorry, but please eat flaming death. Feel better? Patches by mail is, inarguably, the native workflow of git. It's the workflow preferred by the creator and all the early adopters. git's own documentation recommends using "git format-patch origin to prepare patches for e-mail submission to your upstream and send it out." I initially wanted to use git but after spending two weeks with the documentation trying to shoehorn git into my workflow, I switched to mercurial. With mercurial, everything I wanted to do was completely obvious without even referencing the manual. So I believe my point stands. Every VCS has a native workflow, and you should choose the one with a native workflow compatible with your own.
Re: One of many free distributed version-control systems Posted Dec 16, 2007 22:14 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] actually, patches via e-mail is required to be supported by git (Linus insists on that), but it also supports pulling directly from repository to repository, and is heavily used in that mode in kernel development (and in git development for that matter) both workflows could be considered native to git. Linus insists that use of any specific tool (other then a compiler) must not be mandatory in any project he runs, and git reflects that requirement by having 'patches via e-mail' be a first-class transfer protocol in addition to the pull-from-repository transfer options
Re: One of many free distributed version-control systems Posted Dec 16, 2007 23:26 UTC (Sun) by sobdk (guest, #38278) [Link] You're not sorry, because right after you said "I'm sorry" you then proceeded to insult me anyway.Alright, I'm sorry I was quick to interpret your misinformation as a lack of reading the documentation. Patches by mail is, inarguably, the native workflow of git. It's the workflow preferred by the creator and all the early adopters. git's own documentation recommends using "git format-patch origin to prepare patches for e-mail submission to your upstream and send it out." Well, I have to disagree with you here. Patches by mail is indeed a supported workflow in git, but git in no way forces or even encourages you to use this feature. But really this has nothing to do with my original point that git does support push and pull via ssh which your initial comment claimed it did not. Since you did read the documentation but still came to this conclusion then the problem obviously lies in the git documentation (or did when you last looked at it). Could you please explain what led you to believe git doesn't support push and pull? Hearing a new users perspective is always useful for improving documentation. When I was a new user the first place I looked was http://git.or.cz/#documentation I found the tutorial a quick read and very useful. Interestingly after looking at it again it doesn't mention using git-format-patch except for a tiny note at the end. Instead it uses git push and pull. Perhaps you went straight for the man pages? "man git" provides similar information to what I linked including the tutorial, as well as a list of commands with include git push and pull. Maybe you just tried running a commands? "git --help" provides me with a list of commonly used git commands including push and pull, but oddly enough git format-patch is not listed. PS. all of this is with git 1.5.3.7 so perhaps things have changed since you last tried git.
someone needs to document the different workflows Posted Dec 16, 2007 22:30 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] they may each have many native workflows (your misunderstanding of git's 'native workflow' highlights this. one problem is that there is not a lot of documentation on what the possible workflows are, so people tend to think that the way they operate is the best (and sometimes the only) possible workflow. it would be really good if someone (ideally a neutral party, are you reading Grumpy Editor?) were to gather workflows, and then allow each VCS system to document how they would handle that situation. timing information from each on how long the commands take would be a nice bonus, but the difficulties in getting comparable timings (same project history, same hardware, etc) would make this difficult to do, although since there are tools to migrate things from one system to another, it may be possible to let each VCS system convert the project history to their system and then run the commands suggested on a common box. it would be worth doing this on several different project histories to identify where there are scaling problems. given the pace of development such a set of tests would need to be run once or twice a year. I've seen git make very rapid progress when a large project (mozilla or gcc for example) first looked at migrating and ran into scaling issues. I expect that the other projects would eveolve in similar ways when put head-to-head. some may initially say that they shouldn't be used on a project that large, but I somehow doubt that the proponents and developers of any of the projects will really let such statements stand for long if they can avoid it ;-)
Re: One of many free distributed version-control systems Posted Dec 17, 2007 10:20 UTC (Mon) by jamesh (subscriber, #1159) [Link] and sometimes features of a distributed system just make it impossible to do some workflows. for example, the bazaar version numbers don't work in a multi-master workflow, but the bazaar people feel that in a more centralized workflow they simplify things enough that they list them as an advantage over git, where the git people would list them as a disadvantage for bazaar Bazaar's revision numbers remain useful outside of centralised workflows. The main argument from the Git people is that the revision numbers are not globally unique, so therefore useless. In response, I agree that revision numbers are not globally unique but disagree that this makes them useless. In the context of a particular branch, the revision numbers unambiguously map to particular revisions. So provided it is known what branch location is being referred to, you can talk in terms of revision numbers just fine. Furthermore, the most interesting revisions on a branch (those comprising its main line of development) are allocated the shortest numbers (no dotted components). Now this isn't to say that there isn't a place for globally unique identifiers -- this is not uncommon for complex operations that involve multiple branches. Bazaar does associate a globally unique revision ID to each revision, so they can certainly be used in such operations. I think the Git guys do see value in more concise ways of identifying revisions in the context of a particular branch though. In many Git tutorials, I've seen truncated revision IDs used instead of the full SHA1 sums to identify revisions. This appears to be a case of providing convenience at the expense of ambiguity at the global scale. Given that it is unlikely to result in collisions with respect to a particular branch, this seems like a worthwhile compromise similar in spirit to Bazaar's revision numbers.
Re: One of many free distributed version-control systems Posted Dec 14, 2007 23:47 UTC (Fri) by dannyobrien (subscriber, #25583) [Link] I think one would have to also include mercurial in the front-runners, as it's been picked up by Mozilla and OpenSolaris as their DVCS.
Re: One of many free distributed version-control systems Posted Dec 17, 2007 9:28 UTC (Mon) by alceste (subscriber, #39742) [Link] Sun is using Mercurial for JDK development, too: http://hg.openjdk.java.net/ If I understand correctly, the transition to Mercurial has been completed a few days ago. More details on http://weblogs.java.net/blog/kellyohair/
One of many free distributed version-control systems Posted Dec 15, 2007 3:03 UTC (Sat) by sward (subscriber, #6416) [Link] No, we probably don't need this many different DVCS in the long run. But at this stage in their development, there's still a lot of experimentation going on (bzr has gone through, I think, 4 on-disk formats in the time I've been following it; mercurial and git are also evolving very rapidly). Trying to pick a single "winner" (a la cvs) at this point would be premature. It is also worth noting that these DVCS projects do not compete for mindshare in quite the same way as, say, Linux desktop environments do. They are all interoperable to varying degrees, and they all have to interoperate with a host of other development tools if they are going to be widely adopted. And, except for their own plugins/extensions and "glue" code, they aren't really development platforms that serve as a base for a lot of other projects. Bear in mind, there are still lots of competing centralized VCS tools as well (at least commercial ones) - this may not be a tool category that lends itself to winner-take-all consolidation. So, why try to pick the "one true DVCS" now? Let the various experiments evolve for a while (and raid each other for good ideas), and see what turns up. And in the meantime, you can get a lot of useful work done with any of the systems in the current crop.
One of many free distributed version-control systems Posted Dec 15, 2007 4:27 UTC (Sat) by atai (subscriber, #10977) [Link] Yes, that's why Arch will keep evolving as well...
One of many free distributed version-control systems Posted Dec 15, 2007 9:25 UTC (Sat) by davidw (subscriber, #947) [Link] > Trying to pick a single "winner" (a la cvs) at this point would be premature. Sounds like a good reason to avoid the lot of them for the time being, sticking with subversion, and wait and see. I mean, it's version control... not exactly an area where living on the bleeding edge is a good idea for most people and organizations.
One of many free distributed version-control systems Posted Dec 15, 2007 10:01 UTC (Sat) by engla (guest, #47454) [Link] Those who have already learnt a modern DSCM (for example, git) surely say it's worth it if you want to put some effort into it.
One of many free distributed version-control systems Posted Dec 15, 2007 10:08 UTC (Sat) by davidw (subscriber, #947) [Link] git will likely at least be around, if not a winner. What happens if you put some effort into one and it fades away? Then you have wasted your time, and now have your version control history in software that's not going anywhere. I'd rather learn something with some intrinsic value, and let the DVC wars sort themselves out before picking one. By the way, "those who have already" are much more likely to say something is worthwhile, because otherwise they have to admit that they wasted their time. Not saying that this is the case, just that there is some bias involved in those kinds of statements.
One of many free distributed version-control systems Posted Dec 15, 2007 11:50 UTC (Sat) by error27 (subscriber, #8346) [Link] I guess the point is that if git and mercurial are undeniably better than subversion. They are faster and have additional features. If you're happy with what you're currently using then probably that doesn't matter. Another advantage is that they are more reliable in the sense that the repo is less likely to get corrupted. For example, when the kernel was under BK a hacker tried to screw with the repo but it was recognized right away because the checksums didn't match. That kind of hacking attempt would have been caught with git as well. But the bottom line is that if you don't care about speed, features, reliability and security then do what makes you happy. :)
One of many free distributed version-control systems Posted Dec 15, 2007 17:58 UTC (Sat) by stevenj (guest, #421) [Link] What happens if you put some effort into one and it fades away? Then you have wasted your time, and now have your version control history in software that's not going anywhere. Not at all. First, anyone who has used any DVCS will probably tell you that they are a vast improvement over a classic CVS-style VCS, and will certainly save you time and aggravation. CVS is truly primitive in comparison to any modern VCS. And if you learn one DVCS, the concepts carry over well to pretty much any other DVCS. So, you haven't "wasted your time;" quite the opposite. Second, you are not locked in; as I said in my original post, there are already several conversion tools that let you transfer your version history between DVCS systems (and import from CVS or Subversion). This is one of the nice things about using free software and open formats, because FLOSS developers practice what they preach when it comes to interoperability. People who have never used a modern DVCS should be cautious about speaking from ignorance.
One of many free distributed version-control systems Posted Dec 15, 2007 19:36 UTC (Sat) by davidw (subscriber, #947) [Link] I read things like this: http://blog.moertel.com/articles/2007/12/10/how-i-stopped... And what it says to me is that I might as well wait until a winner emerges. svn is "good enough" for me, like it is for many other people. With a limited amount of time at my disposition, "good enough" is a conscious choice to not bother with "better/best" until the better option has been fairly well nailed down. The name for this behavior is "satisficing", as opposed to maximizing, and in reality, is something that we must all do. We can't all follow the latest and greatest in everything in our lives - it's simply not possible in terms of time constraints. For some people, the benefits of a bleeding edge version control system may be worth the costs, for many others, they're not. For some people, playing around with the latest version of Erlang, Haskell, Ocaml or Scala is critical. For other people, that's not important. Some people need to follow the development of the Linux kernel in order to keep on top of improvements for massive server deployments. That's not so important for other people. The point is that it is, like many things, a tradeoff, and that chasing after the latest thing in this field may quite well be a waste of time for some people, such as myself, for whom existing systems like svn are adequate, even if we realize that better things are available.
One of many free distributed version-control systems Posted Dec 15, 2007 21:10 UTC (Sat) by sward (subscriber, #6416) [Link] Surely, you should continue to use Subversion if it meets your needs. Version control tools are not something you want to switch lightly (although the switching costs really aren't that high). I would not class bzr, hg, or git (or svk, for that matter) as "bleeding edge" anymore. They've all been used successfully on real projects. And the risk of lockin is minimal, given the conversion tools that already exist for all the major version control systems.
One of many free distributed version-control systems Posted Dec 17, 2007 8:06 UTC (Mon) by aleXXX (subscriber, #2742) [Link] > (although the switching costs really aren't that high) The switching costs can be high. If you are in a commercial setting with developers on UNIX and Windows platforms, then the switching costs can be really high. Switching the VCS means -several man days if not weeks for somebody to evaluate the alternatives, including finding mature GUI clients for all platforms -a few man days for the VCS admin to actually do the switch (maybe creating the new repo doesn't take long, but it has to be made sure that it really works, has everything, permissions are correct, history is correct etc.) -1 day for everybody for a quick introduction to the new system -some time for each developer to learn the new stuff -several man days for the VCS admin for helping the newbies Sum this up and depending on the number of people you can get man months. And you may have developers who are not that flexible, and don't like to change in general. If they are not really pro-open source, switching from one open source VCS to another open source VCS will make them think even worse about open source: "we have to change all the time, because the previous one didn't work." Having a solution which works for years really gives them a feeling of stability and reliability, switching once a year feels like "nothing is good enough to rely on". Alex
One of many free distributed version-control systems Posted Dec 16, 2007 6:14 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] while the various DVCS systems all have differences, they all have more in common with each other then they do with any of the non-distributed ones. and just like learning CVS gives you a head start if you then start using Perforce, learning any one DVCS system will give you a head start in understanding the rest of them. there's value in entering this new area, even if the particular tool that you start with doesn't end up being the one that you keep useing.
DVCS is cool, as is bzr Posted Dec 15, 2007 14:19 UTC (Sat) by kevinbsmith (guest, #4778) [Link] So far, each system has focused on a different key feature (or small set of features). Over time, I wouldn't be surprised if many of them evolve to be equally good in several ways, at which point some may fade away. For me, git loses immediately because it's not really cross-platform, and almost all my work is on cross-platform apps. For me, one of bzr's important benefits was the ability to host repos on a dirt-cheap html-only web host (unlike, for example, monotone). I see two HUGE benefits of DVCS over centralized systems like subversion: 1. Offline development. If I want to work on a plane, or in a hotel room in a remote country, or on a park bench in a town without wi-fi, it's nice to have full version control capabilities. 2. Democratization of FLOSS development. It's really great to be able to work on a project without having to plead for the right to write to the central repo. In the long run, I think #2 is going to cause significant shifts in how FLOSS projects are managed, and will greatly increase participation by developers. The linked article actually covers that pretty well. A lot of people who evaluate DVCS overlook (or underestimate) that one. One cool feature of bzr is the plugin that allows it to directly read from and write to a subversion repository. So you can start to play with bzr even if the project is still using svn. Between that and the eclipse plugin, I may be able to experiment with bzr at work.
DVCS is cool, as is bzr Posted Dec 15, 2007 21:21 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] git supports many platforms, the only significant platform it doesn't support is a native windows port (and there are people working on that). the biggest reason for this lack is that git uses scripts for many things, and windows doesn't provide a posix scripting environment. if you can provide such an environment (with cygwin) then git will work just fine. I agree with you that your point #2 (the ability to work without getting commit rights to the central repository) is likely to be far more important over time. Linus has been extremely adament during the git development that the tool should not require such a hirearchy, but instead leave that to config options and social conventions.
DVCS is cool, as is bzr Posted Dec 16, 2007 1:51 UTC (Sun) by tetromino (subscriber, #33846) [Link] > git supports many platforms, the only significant platform it doesn't support is a native windows port There are only 3 platforms that are relevant in the real world: Windows, Linux, and OSX. Git supports 2 of them - that's not exactly "many". > the biggest reason for this lack is that git uses scripts for many things, and windows doesn't provide a posix scripting environment. My impression was that the biggest problem is that git's on-disk layout is very slow on NTFS.
DVCS is cool, as is bzr Posted Dec 16, 2007 6:10 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] even by that argument git is cross platform (it supports OSX just fine) :-) I hadn't heard anything about any incompatibility with NTFS. forks on windows are slow, and that hurts scripts, but the problem with git on windows isn't that it's so slow that it's unusable (it is slower then on *nix, but so are a lot of things :-) but that people aren't willing to consider git running under cygwin to make windows a 'supported' platform
Git + portability Posted Dec 18, 2007 17:24 UTC (Tue) by madscientist (subscriber, #16861) [Link] A more accurate statement is that git is not portable. Yes, it works on various UNIX and UNIX-like systems (OSX is also a UNIX system). But the code currently requires various features of UNIX/POSIX. Even the responses to these comments (use Cygwin) are just a way of avoiding portability in the tool by forcing the user to emulate UNIX/POSIX underneath it. It was not designed to be portable in that way. And that's fine, because that's what the people using git care about mostly. But it's a mark against it for folks who need to work with non-POSIX systems. It could well be that the other DVCS systems mentioned here also have this problem; I don't know. I do know git has it, and I know that Subversion doesn't: Subversion was designed from day one to be maximally portable. Not only does it run on POSIX systems and native Windows, but it also runs on OS/2 and BeOS for sure, and can be fairly easily ported to many other platforms (at least the client).
DVCS is cool, as is bzr Posted Dec 27, 2007 14:21 UTC (Thu) by broonie (subscriber, #7078) [Link] The other thing DVCSs tend to do well is merging - due to the many lines of development you end up with they pretty much have to or they fall over badly. Even in a centralised setup that can be a big win. git also has a svn client, FWIW. I've never tried to use it but I know a lot of people like it.
One of many free distributed version-control systems Posted Dec 16, 2007 6:47 UTC (Sun) by zooko (subscriber, #2589) [Link] The first public alpha release of darcs 2 just came out, and claims to have solved the fatal problem in which darcs uses exponential time-complexity algorithms to resolve certain kinds of merges. This gives me renewed hope for the darcs project.
|
|
||||||||||||