From felipe.contreras@gmail.com Tue Jul 8 16:17:52 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Jul 2008 23:17:52 +0300 Subject: Monotone analysis Message-ID: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Status: O Content-Length: 6329 Lines: 200 Hi everybody, This is an attempt to shed light into some deficiencies of Monotone and how other DSCMs do the same things. I'm not attempting to make you switch your DSCM, just present my findings. I order to do that I'll explain what monotone is and how it works internally. Some people argue that in a good SCM you don't need to know the details of the implementation, but quite often understanding the details helps to understand why some operations are not so efficient and will never be. = Overview = Monotone is a DSCM that has some time already, and it's distinctive because it values correctness over optimization. Despite of its long time of existence, very few projects use it. The most important ones are OpenEmbedded and Pidgin. = Certs = In order to understand most of the issues in Monotone you need to understand what a cert is. A cert is basically metadata signed by some person. It could be anything, it's a key string, and a string value, that's it. A person can set multiple keys with different values, and two persons can set the same keys. Some common certs are: author, date, branch, changelog, tag, comment. == Branches == Branches are just certs. That means that a revision can have a multitude of branches, according to different developers. For example, John can say cert 476eb8 is in branch im.john, while Leo can say it's in im.experimental. That also means ce5b79 can also be on im.experimental and be completely unrelated to 476eb8. This is important; completely unrelated revisions can be on the same branch. This design affects performance, as there is no sane way to traverse a branch but to search through the whole repository for the commits. And still, it would be tricky. Even if you manage to get all the revisions of a branch, how to represent them can be tricky because of this deisgn. == Dates == A similar thing happens with commits between certain date ranges. Since dates are just certs, finding revisions between certain ranges requires cheking all the revisions. It's not efficient. == Changelog == Another curious thing aobut certs is that you can actually set many different changelogs. Each developer can set a different message for the same revision. It's confusing, and annoying. == Solution == In other DSCMS (git, bzr, hg) a revision is not complete without commiter, author, date, and message. So you can't have more than one of these values or the revision would be different. This makes things easier. = Storage = The way each revision is stored is crucial; it defines how many operations behave. In Monotone, revisions are stored as deltas from the previous one. This means operations like checkout take a lot of time, specially as revisions accumulate. In order to get the last revision you need to get all the previous ones. Also, if you try to compare (diff) two revisions that are very far away, you would have to accumulate the differences of all the revisions in the middle; it's also expensive. == Solution == In other DSCMS (git, bzr) revisions are stored individually, and if they are similar they are compressed. That achieves the same goal as just storing deltas; saving space. But also achieves the goal of efficiency on different operations. = Workflow = Most DSCMS base on the fact that branches are cheap. That allows for a branch for each developer, topic branches and temporal branches. == Bazaar == In Bazaar each branch is developed separately. That means there's only one head on each branch, and each developer has it's own branch, and often, multiple branches. So each branch is simple; you can traverse it by looking at the parents of the head of the branch. Creating and destroying branches is as easy as creating and destroying directories. More over, thanks to bzr's extensibility it's possible to have temporal branches and use them properly with the rebase plugin. == Git == In Git, each branch has only one head. So it's similar to bzr; branches are simple. A repository can have a multitude of branches which are simply points to a commit. That means you can have as much branchs as you like, some only local, some only remote, and some linked. = Popularity = The SCM used by a project is a key issue. It restricts, or allows different workflows, and makes it easier or harder for new contributors to get started. The more popular the SCM of choice is, the higher the chances of a new contributor already familiar with it, and so, the more chances of getting new contributors up to speed quickly. Also, the more popular the SCM, the more tools available to it. For example; GUIs, web services, hosting facilities, project tracking plugins (Trac), etc. The more popular DSCMs right now are git and bzr, with hg not so far away. Choosing anything else doesn't seem to be a wise choice. = Git recommendation = In some conversations in #pidgin some developers (elb, deryini) made apparent their dislike for git. Apparently some people think that only the Linux Kernel guys are using git, and they are doing things the wrong way. Linux being probably the most successfull open source software project, I find that arrogant and unfounded; their workflow is much more efficient than anybody else's. They achieve 3.7 commits per hour, and always stable; that wouldn't be possible without a decent DSCM. Perhaps these projects are wrong too[1]: * Linux Kernel * X.org * Debian (build-tools, debpool, pbuilder) * Fedora * GNU autoconf, automake, core-utils * Compiz Fusion * PackageKit * ALSA * Cairo * HAL * D-Bus * Mesa3D * OLPC * Wine * fluxbox * Yum * Ruby on Rails * Samba * KVM * VLC * x264 And recently PulseAudio, and GStreamer is on the way too. Both KDE and GNOME have git clones of their svn repositories, and are in the discussions about moving to a DSCM with git as the strongest option. The only big issue with git in the past was Windows support, but that's not an issue anymore with msysgit[2]. There are many GUIs, web services, hosting sites, a plugin for Trac, screen casts, blogs, tutorials, etc. There is a reason for that; git is awesome. I'm not interested in silly discussions; if you have a doubt about git, I'll try to answer it. Best regards. [1] http://git.or.cz/gitwiki/GitProjects [2] http://code.google.com/p/msysgit/ -- Felipe Contreras From ecoffey@gmail.com Tue Jul 8 16:39:01 2008 From: ecoffey at gmail.com (Eoin Coffey) Date: Tue, 8 Jul 2008 14:39:01 -0600 Subject: Monotone analysis In-Reply-To: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: <2d88cc360807081339kab1f728le8cd0f32c4563f2e@mail.gmail.com> Status: O Content-Length: 816 Lines: 26 On Tue, Jul 8, 2008 at 2:17 PM, Felipe Contreras wrote: > I'm not attempting to make you switch your > DSCM, just present my findings. = Git recommendation = hmmmm :-) FWIW, I'm pretty sure that Pidgin switched to monotone while git was still young, and not yet gaining in popularity. I'm not debating your technical reasoning for using Git over something else, I just don't like that you keep on insinuating that the *original* reason Pidgin didn't use Git was because of some knee jerk reaction to it. Or maybe that *is* the case :-P I just remember that monotone was the best looking at the time. -Eoin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://pidgin.im/pipermail/devel/attachments/20080708/de7f6379/attachment.htm From khc@hxbc.us Tue Jul 8 16:45:19 2008 From: khc at hxbc.us (Ka-Hing Cheung) Date: Tue, 08 Jul 2008 13:45:19 -0700 Subject: Monotone analysis In-Reply-To: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: <1215549919.7566.54.camel@struggle64> Status: O Content-Length: 960 Lines: 23 On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > = Git recommendation = ?Sure monotone is slower, but is it fast enough? Sure the monotone db is bigger, but is it really that much of a problem? Maybe there are less tools for monotone, but the extra tools for other DVCSs are worthless if we don't plan to use them anyway. While I don't dislike git or anything else, and think that starting with monotone now is a little silly, I think the important thing here is whether the cost of switching is worth it. Many of us spent quite a while to learn monotone already, and it's hard to spend time to learn something else unless it's clear that there's significant return. Also, if we switch to X now, should we switch to Y when that becomes _better_? Pidgin isn't in the business of developing DVCSs. If monotone becomes not good enough, or if there's a clear winner in the DVCS space, then ya, maybe it's silly to keep using monotone then. -khc From felipe.contreras@gmail.com Tue Jul 8 18:05:20 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 01:05:20 +0300 Subject: Monotone analysis In-Reply-To: <1215549919.7566.54.camel@struggle64> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> Message-ID: <94a0d4530807081505j7f9e9677qac1be292a0a33bb1@mail.gmail.com> Status: O Content-Length: 2939 Lines: 68 On Tue, Jul 8, 2008 at 11:45 PM, Ka-Hing Cheung wrote: > On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> = Git recommendation = > > ?Sure monotone is slower, but is it fast enough? Sure the monotone db is > bigger, but is it really that much of a problem? At some point in time 1M of ram was enough for most people, now it's not. It depends on what you do, right? Except that what you can do depends on what you have. You can say mtn is fast enough for what you do, but that doesn't mean that if you have something faster you won't be doing much more. For example, 'mtn log' takes 62 seconds in my laptop, while 'git log' takes 0.93 seconds. Is 'mtn log' fast enough? Well, that depends on how often you do 'mtn log', and paradoxically, how often you do 'mtn log' depends on how fast it is. That's a physiologic feature of human beings; we must find ways to be happy with what we have. It doesn't make sense to get desperate with how slow a 100mhz computer was decades ago, but it does right now, because now we can have something better. > Maybe there are less > tools for monotone, but the extra tools for other DVCSs are worthless if > we don't plan to use them anyway. Again cyclic stuff; you don't plan to use them because you couldn't have them. > While I don't dislike git or anything else, and think that starting with > monotone now is a little silly, I think the important thing here is > whether the cost of switching is worth it. Many of us spent quite a > while to learn monotone already, and it's hard to spend time to learn > something else unless it's clear that there's significant return. Also, > if we switch to X now, should we switch to Y when that becomes _better_? > > Pidgin isn't in the business of developing DVCSs. If monotone becomes > not good enough, or if there's a clear winner in the DVCS space, then > ya, maybe it's silly to keep using monotone then. I think the false assumption here is that Monotone was a good choice at the time; it wasn't. I've been reminded several times that you did your homework and studied carefully all the options, but a quick look at the repository format would have shown all the mtn deficiencies I've mentioned. The UIs, documentation, platform support, all those can change and improve, but the underlying design doesn't. Keith Packard understood this, and chose git knowing that the fundamentals where right [1]. It's sensible to wait for a clear winner in the DSCM wars, that's why I don't get why you chose mtn when I think it was never a clear winner. In any case; the important thing as you say is the cost of switching. I bet switching to mtn was painful, but that doesn't mean switching to git would be, that's why I mentioned all the GUIs, tools, tutorials, etc. I've witnessed projects switching to git in a matter of weeks; not a big deal. [1] http://keithp.com/blogs/Repository_Formats_Matter/ -- Felipe Contreras From rlaager@wiktel.com Tue Jul 8 18:56:03 2008 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 08 Jul 2008 17:56:03 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: <1215557763.8810.42.camel@watermelon.coderich.net> Status: O Content-Length: 6757 Lines: 176 On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > A cert is basically metadata signed by some person. It could be anything, it's > a key string, and a string value, that's it. This opens up some really interesting workflow possibilities that wouldn't exist otherwise. That said, I'll stipulate that nobody seems to be interested in doing these things in the real world right now, which is really sad. I have a great example of where this would be useful, though: Right now, the kernel developers are doing Signed-Off-By markers (and the like) in commits. Monotone has built-in support for this (with real crypto backing it, even). It's also possible for someone like Linus to configure Monotone to ignore all revisions that aren't signed by his Lieutenants. > there is no sane way to traverse a branch > but to search through the whole repository for the commits. I don't know what you mean by "traverse a branch". > A similar thing happens with commits between certain date ranges. > Since dates are > just certs, finding revisions between certain ranges requires cheking all the > revisions. It involves checking all the certs, which can be indexed (it's a SQL database, after all): SELECT * FROM certs WHERE ... > It's not efficient. I'm curious how this looks in Git. > Another curious thing aobut certs is that you can actually set many different > changelogs. Each developer can set a different message for the same revision. > > It's confusing, and annoying. This is an excellent feature. It allows you to go back and add more information after the fact. > In other DSCMS (git, bzr, hg) a revision is not complete without commiter, > author, date, and message. So you can't have more than one of these > values or the > revision would be different. How does git deal with this case? Imagine a branch with two heads. A |\ | \ | \ | | B C Two people each merge them: ?A |\ | \ | \ | | B C \ / D Then they push their changes. In Monotone, they both created the same revision D with a set of certs, so this collapses nicely. Does git lead to two new heads? (Or, since you can't have two heads in git, does it force a merge?) > In other DSCMS (git, bzr) revisions are stored individually, and if they are > similar they are compressed. That achieves the same goal as just storing > deltas; saving space. But also achieves the goal of efficiency on different > operations. This makes it more expensive to show a diff between two adjacent revisions, a common operation. That said, from what I hear, git's compression these days is SO GOOD that it achieves huge wins here. > In Bazaar each branch is developed separately. That means there's only one > head on each branch Imagine a branch like this: A -> B -> C -> D If I have two checkouts from that and I make a different commit from each, what happens? In Monotone, I get two heads. Is BZR/git/hg/whatever going to stop me from committing the second change until I merge it up with the new head? If so, I think this is a fundamental design flaw because I can't easily preserve the state of the code BEFORE a risky merge. > So each branch is simple; you can traverse it by looking at the parents of the > head of the branch. If this is your definition of traversing a branch, you can do the same thing in Monotone, so I don't understand your concern above. > In Git, each branch has only one head. So it's similar to bzr; branches are > simple. Same question as above. How do you prevent multiple heads from happening? > = Popularity = > The more popular DSCMs right now are git and bzr, with hg not so far away. > Choosing anything else doesn't seem to be a wise choice. Right. I think this is also a potentially compelling reason to switch. ?On Wed, 2008-07-09 at 01:05 +0300, Felipe Contreras wrote: > Keith Packard understood this, and chose git knowing that the > fundamentals where right [1]. Half of that document explains why a DVCS is better than a CVCS, so that's not really a difference here. Monotone has a much more flexible representation (with certs being generic). Here your argument cuts against you. If you want to do something new with git, you have to write support for another "column" (using SQL terminology) in your "table", whereas with Monotone, you just create the cert. For example, let's say you had Signed-Off-By (which you don't) and now you want to add Reviewed-By... "Files containing object data are never modified. Once written, every file is read-only from that point forward." s/Files containing/ and this applies to Monotone. In fact, that's where it gets its name. There's always the danger that the database could be corrupted. Basically, here we're comparing the potential for corrupting a single file database vs. a directory tree of files. In all reality, I don't think it's that big of a difference, but I do tend to trust ext3 more than sqlite. Of course, with this being about *distributed* version control systems, you end up with backups all around the world regardless of which system you choose. However, if the files are write-once, then you must end up with at least one file per revision (except, perhaps for imports where you could batch up the existing revisions). This leads to the criticism being applied against SVN: "The FSFS backend places one file per revision in a single directory; a test import of Mozilla generated hundreds of thousands of files in this directory, causing performance to plummet as more revisions were imported." How does git do write-once files without having one file per revision? > In any case; the important thing as you say is the cost of switching. > I bet switching to mtn was painful, but that doesn't mean switching to > git would be Converting the repository from SVN was painful, which wouldn't be incurred again. Learning DVCS concepts was some work, which also wouldn't be duplicated. I don't think that switching would be all that difficult and I like the idea of choosing something that contributors would be more familiar with (as well as something that has good hosting opportunities so said contributors can really take advantage of the branch-sharing workflow). I think the really killer application here is something like Launchpad, with integrated code hosting, code review, bug tracking, etc. If we decide to switch, I'd like to wait just a little longer before we do it to see how git vs. bzr is going to turn out so we don't end up switching twice. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080708/14d3280e/attachment-0001.pgp From felipe.contreras@gmail.com Tue Jul 8 20:32:06 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 03:32:06 +0300 Subject: Monotone analysis In-Reply-To: <1215557763.8810.42.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215557763.8810.42.camel@watermelon.coderich.net> Message-ID: <94a0d4530807081732g2c671b62i2dfb5e25b43e40d1@mail.gmail.com> Status: O Content-Length: 10275 Lines: 255 On Wed, Jul 9, 2008 at 1:56 AM, Richard Laager wrote: > On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> A cert is basically metadata signed by some person. It could be anything, it's >> a key string, and a string value, that's it. > > This opens up some really interesting workflow possibilities that > wouldn't exist otherwise. That said, I'll stipulate that nobody seems to > be interested in doing these things in the real world right now, which > is really sad. > > I have a great example of where this would be useful, though: Right now, > the kernel developers are doing Signed-Off-By markers (and the like) in > commits. Monotone has built-in support for this (with real crypto > backing it, even). It's also possible for someone like Linus to > configure Monotone to ignore all revisions that aren't signed by his > Lieutenants. I don't see how can revisions be "ignored", but Linus can already do that by grepping the logs. There's no need for integrated cryptography because Linus is responsible for verifying the identity of his lieutenants. It could be by ssh, a patch sent through email and verified with PGP. It's a network of trust, as Linus points out; the only way to do real security. >> there is no sane way to traverse a branch >> but to search through the whole repository for the commits. > > I don't know what you mean by "traverse a branch". Go from the head of the branch to the tails, commit by commit. In git you have one head commit, and the you just visit the parents recursively. >> A similar thing happens with commits between certain date ranges. >> Since dates are >> just certs, finding revisions between certain ranges requires cheking all the >> revisions. > > It involves checking all the certs, which can be indexed (it's a SQL > database, after all): SELECT * FROM certs WHERE ... Exactly, but then if you want to get the commit message the query must be different, and specially since you can have more than one commit message. >> It's not efficient. > > I'm curious how this looks in Git. It's the same, except you traverse only the branch (not all the commits), and all the relevant information is readily available. >> Another curious thing aobut certs is that you can actually set many different >> changelogs. Each developer can set a different message for the same revision. >> >> It's confusing, and annoying. > > This is an excellent feature. It allows you to go back and add more > information after the fact. Or remove information, so the integrity is never really ensured. In git you can also alter the information, but if you do that, then it's effectively creating new commits, which is exactly what you would want. Otherwise how you know that you are looking at the same information when the sha1s are the same but the information might not? >> In other DSCMS (git, bzr, hg) a revision is not complete without commiter, >> author, date, and message. So you can't have more than one of these >> values or the >> revision would be different. > > How does git deal with this case? > > Imagine a branch with two heads. > A > |\ > | \ > | \ > | | > B C There is only one head per branch. > Two people each merge them: > ?A > |\ > | \ > | \ > | | > B C > \ / > D > > Then they push their changes. In Monotone, they both created the same > revision D with a set of certs, so this collapses nicely. Does git lead > to two new heads? (Or, since you can't have two heads in git, does it > force a merge?) Let's suppose that 'john' and 'steven' both apply a patch somebody submitted. The two commits would have the same code, but the information would be different (different committer, different date, different message), so effectively these are two different commits. These commits would be on different branches: 'john/master' and 'steven/master'. Assuming there's one central repository and both have access to it, let's say 'steven' pushes the commit first, then when 'john' tries to do the same there will be a merge conflict, which would be resolved, but would create an empty commit. Then 'john' realizes his commit is no longer valid and just drops it. In this case git is doing the right thing; telling exactly what is happening, and letting you handle the conflicts. >> In other DSCMS (git, bzr) revisions are stored individually, and if they are >> similar they are compressed. That achieves the same goal as just storing >> deltas; saving space. But also achieves the goal of efficiency on different >> operations. > > This makes it more expensive to show a diff between two adjacent > revisions, a common operation. That said, from what I hear, git's > compression these days is SO GOOD that it achieves huge wins here. Only if there are massive changes which is usually not the case, and even then it's quite fast. >> In Bazaar each branch is developed separately. That means there's only one >> head on each branch > > Imagine a branch like this: > > A -> B -> C -> D > > If I have two checkouts from that and I make a different commit from > each, what happens? In Monotone, I get two heads. Is BZR/git/hg/whatever > going to stop me from committing the second change until I merge it up > with the new head? If so, I think this is a fundamental design flaw > because I can't easily preserve the state of the code BEFORE a risky > merge. Each checkout is a different branch, you can continue the development as much as you want and merge whenever you want. I think you are confused by what a 'commit' means in other DSCMs. In montone, a local commit is going to spread across all repositories as soon as you sync. In other DSCMs a local commit is just that; you decide if you want to distribute it, or keep it local. >> So each branch is simple; you can traverse it by looking at the parents of the >> head of the branch. > > If this is your definition of traversing a branch, you can do the same > thing in Monotone, so I don't understand your concern above. No, in mtn a branch can have completely unrelated commits; not connected by any sequence of commits. While it probably doesn't happen in real life, the database design allows it. So you don't traverse branches in mtn, you just dump all the commits in it. >> In Git, each branch has only one head. So it's similar to bzr; branches are >> simple. > > Same question as above. How do you prevent multiple heads from > happening? Multiple branches. >> = Popularity = > >> The more popular DSCMs right now are git and bzr, with hg not so far away. >> Choosing anything else doesn't seem to be a wise choice. > > Right. I think this is also a potentially compelling reason to switch. > > ?On Wed, 2008-07-09 at 01:05 +0300, Felipe Contreras wrote: >> Keith Packard understood this, and chose git knowing that the >> fundamentals where right [1]. > > Half of that document explains why a DVCS is better than a CVCS, so > that's not really a difference here. The important point is that the internal design matters. > Monotone has a much more flexible representation (with certs being > generic). Here your argument cuts against you. If you want to do > something new with git, you have to write support for another > "column" (using SQL terminology) in your "table", whereas with Monotone, > you just create the cert. For example, let's say you had Signed-Off-By > (which you don't) and now you want to add Reviewed-By... > > "Files containing object data are never modified. Once written, every > file is read-only from that point forward." > > s/Files containing/ and this applies to Monotone. In fact, that's where > it gets its name. There's always the danger that the database could be > corrupted. Basically, here we're comparing the potential for corrupting > a single file database vs. a directory tree of files. In all reality, I > don't think it's that big of a difference, but I do tend to trust ext3 > more than sqlite. Of course, with this being about *distributed* version > control systems, you end up with backups all around the world regardless > of which system you choose. Except it's very easy to check the integrity in git: the sha1 ensures you that the information hasn't been altered. All the dates, committers, signed off, changelogs, are ok, if the sha1 is the same that you had. It's funny that git is better at doing what mtn was set to do, but after all Linus got inspiration from it. > However, if the files are write-once, then you must end up with at least > one file per revision (except, perhaps for imports where you could batch > up the existing revisions). This leads to the criticism being applied > against SVN: "The FSFS backend places one file per revision in a single > directory; a test import of Mozilla generated hundreds of thousands of > files in this directory, causing performance to plummet as more > revisions were imported." How does git do write-once files without > having one file per revision? That's one of the things that I personally find more clever about git; each file has a calculated sha1, so if the if the file hasn't changed, the sha1 is the same, so there's no need to store it again, and if you do, nothing would change anyway. It's like hardlinks, with sha1s. >> In any case; the important thing as you say is the cost of switching. >> I bet switching to mtn was painful, but that doesn't mean switching to >> git would be > > Converting the repository from SVN was painful, which wouldn't be > incurred again. Learning DVCS concepts was some work, which also > wouldn't be duplicated. > > I don't think that switching would be all that difficult and I like the > idea of choosing something that contributors would be more familiar with > (as well as something that has good hosting opportunities so said > contributors can really take advantage of the branch-sharing workflow). > I think the really killer application here is something like Launchpad, > with integrated code hosting, code review, bug tracking, etc. Indeed, although Launchpad is closed source. > If we decide to switch, I'd like to wait just a little longer before we > do it to see how git vs. bzr is going to turn out so we don't end up > switching twice. Right, I think those two are sensible options, mtn is not. -- Felipe Contreras From rlaager@wiktel.com Tue Jul 8 20:58:46 2008 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 08 Jul 2008 19:58:46 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807081732g2c671b62i2dfb5e25b43e40d1@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215557763.8810.42.camel@watermelon.coderich.net> <94a0d4530807081732g2c671b62i2dfb5e25b43e40d1@mail.gmail.com> Message-ID: <1215565126.8810.56.camel@watermelon.coderich.net> Status: O Content-Length: 1135 Lines: 23 It's very clear from this response that you do not understand Monotone's design. As the time spent correcting your misunderstandings is not useful to you or me (because you're fine with git anyway and because it has no bearing on the project's choices), I'm not going to bother. I'm sure that git would be a fine choice. However, I don't think that we should switch DVCSs because everyone is doing it. I think we should look at the larger picture: I think that we'd be best served switching to an integrated hosting solution so we only need to run (at most) Apache and Mailman (and that only because we want to use our own domain). This would free us from having to maintain Trac, ViewMTN, commit scripts, etc. However, at the moment, I don't see such a solution that would be sufficiently better than what we have setup now to justify switching. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080708/0c485d53/attachment.pgp From felipe.contreras@gmail.com Tue Jul 8 21:15:58 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 04:15:58 +0300 Subject: Monotone analysis In-Reply-To: <1215565126.8810.56.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215557763.8810.42.camel@watermelon.coderich.net> <94a0d4530807081732g2c671b62i2dfb5e25b43e40d1@mail.gmail.com> <1215565126.8810.56.camel@watermelon.coderich.net> Message-ID: <94a0d4530807081815r41f2621dp616541fbeea3c93b@mail.gmail.com> Status: O Content-Length: 592 Lines: 16 On Wed, Jul 9, 2008 at 3:58 AM, Richard Laager wrote: > It's very clear from this response that you do not understand Monotone's > design. As the time spent correcting your misunderstandings is not > useful to you or me (because you're fine with git anyway and because it > has no bearing on the project's choices), I'm not going to bother. What makes you think I don't understand monotone's design? I spent considerable amount of time writing this, I would hate to see all this work go to the trash in the record with no explanation at all. -- Felipe Contreras From tim.ringenbach@gmail.com Wed Jul 9 00:12:48 2008 From: tim.ringenbach at gmail.com (Tim Ringenbach) Date: Tue, 8 Jul 2008 23:12:48 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: <36a74c840807082112o26fa59bbs429f2083ed005090@mail.gmail.com> Status: O Content-Length: 379 Lines: 10 On Tue, Jul 8, 2008 at 3:17 PM, Felipe Contreras wrote: > They achieve 3.7 commits per hour, and always stable; that wouldn't be possible > without a decent DSCM. (I'm probably being both picky and offtopic here, but...) Are you sure that "wouldn't be possible" part is true? The kernel got by for quite some time with the CSCM known as Linus. From felipe.contreras@gmail.com Wed Jul 9 04:40:00 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 11:40:00 +0300 Subject: Monotone analysis In-Reply-To: <36a74c840807082112o26fa59bbs429f2083ed005090@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <36a74c840807082112o26fa59bbs429f2083ed005090@mail.gmail.com> Message-ID: <94a0d4530807090140l13ad94d2n83c620e3f3782c8@mail.gmail.com> Status: O Content-Length: 619 Lines: 17 On Wed, Jul 9, 2008 at 7:12 AM, Tim Ringenbach wrote: > On Tue, Jul 8, 2008 at 3:17 PM, Felipe Contreras > wrote: >> They achieve 3.7 commits per hour, and always stable; that wouldn't be possible >> without a decent DSCM. > > (I'm probably being both picky and offtopic here, but...) Are you sure > that "wouldn't be possible" part is true? The kernel got by for quite > some time with the CSCM known as Linus. But not 3.7 commit per hour. That's a number that has been increasing with the time and only lately it has reached 3.7. -- Felipe Contreras From lschiere@pidgin.im Wed Jul 9 07:38:26 2008 From: lschiere at pidgin.im (Luke Schierer) Date: Wed, 9 Jul 2008 07:38:26 -0400 Subject: Monotone analysis In-Reply-To: <1215549919.7566.54.camel@struggle64> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> Message-ID: <20080709113825.GI20474@pidgin.im> Status: O Content-Length: 4646 Lines: 88 On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: > On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > > = Git recommendation = > > ?Sure monotone is slower, but is it fast enough? Sure the monotone db is > bigger, but is it really that much of a problem? Maybe there are less > tools for monotone, but the extra tools for other DVCSs are worthless if > we don't plan to use them anyway. > > While I don't dislike git or anything else, and think that starting with > monotone now is a little silly, I think the important thing here is > whether the cost of switching is worth it. Many of us spent quite a > while to learn monotone already, and it's hard to spend time to learn > something else unless it's clear that there's significant return. Also, > if we switch to X now, should we switch to Y when that becomes _better_? > > Pidgin isn't in the business of developing DVCSs. If monotone becomes > not good enough, or if there's a clear winner in the DVCS space, then > ya, maybe it's silly to keep using monotone then. > > -khc Git must have really improved since we made the switch to monotone. I did some digging around, and since I am quite nearly an invenerate pack-rat, I found a working copy of a git repo I created back when we were evaluating which dvcs to use. The git repo from then is 649M, my much much newer monotone database is only 244M. I recall that the size of a git database was such a problem that the kernel developers weren't even trying to use a database with an entire history in it, they dumped all their historical stuff in one repository and had another with just the 2.6 stuff in it. Looking at it now, it appears that their basic work flow is that anytime someone does significant enough work that someone else might want to help them with it, before it is merged into the one head, they create a new download target on git.kernel.org. Though I could be wrong here, I've spent very little time thinking about git since we made the decision, and I'm a little foggy on how it works now. Still, there are some important things to remember here. We spent considerable time and effort evaluating our options when we made this switch. I am a little tired of the idea that we made it relatively arbitrarily. At the time there were a number of apparently equally viable DVCS. I looked at _all_ of them, including git, bzr. hg, at the time, was not even used by redhat, and did not appear to be really viable, so I admit I did not look at it. Of the ones out there, while a fair few had started implementing subversion -> $dvcs support, only two had _working_ support, git and monotone. At least, several had support that _appeared_ like it it _might_ work for much smaller repositories, but only two could handle _ours_. We wanted to have the full history available to us. Of them, git, at the time, as you claim this is solved, required almost a full CDs worth of space just for the repository. Unlike monotone, this repository has to be stored _per working copy_. That means if I am working on head in pidgin.my/ and gobjectification in pidgin.gobject/ and 2.4.x in pidgin.2.4/ then I incur this cost 3 times, whereas with montone I have one database, and so incur the cost once. Monotone _could_ be larger than a git repo and still be a clear winner (space wise) on this alone. In fact, this was one of the deciding factors in picking monotone over git. Several developers expressed a very strong dis-interest in re-learning their work flows to be able to effecitently work on multiple projects in one working copy. Another consideration is that downloading an ISO's worth of data is, or at least was, non-trivial for a substantial number of people, again this was a concerned expressed by some developers at the time. Would you really consider working on pidgin to contribute that one patch if you had to download that much just to get going with our DVCS? While I have always been attracted to git _because_ it is used by the kernel developers, and I figure that this fact will ensure that it continues to be improved on, and ensures that it will continue to have a substantial body of users who are familiar with it, I really don't think our choice of monotone was unreasonable given where we were at the time. I wouldn't mind switching now if 1)there were a clear benefit to doing so and 2)a degree of certainty that we won't be switching again in another couple years. That being said, I don't think we want to throw away our work on trac _now_, so we'd want to make sure all the pieces were in place for trac integration _before_ the switch. Luke From felipe.contreras@gmail.com Wed Jul 9 09:04:03 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 16:04:03 +0300 Subject: Monotone analysis In-Reply-To: <20080709113825.GI20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> Message-ID: <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> Status: O Content-Length: 6118 Lines: 120 On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> > = Git recommendation = >> >> ?Sure monotone is slower, but is it fast enough? Sure the monotone db is >> bigger, but is it really that much of a problem? Maybe there are less >> tools for monotone, but the extra tools for other DVCSs are worthless if >> we don't plan to use them anyway. >> >> While I don't dislike git or anything else, and think that starting with >> monotone now is a little silly, I think the important thing here is >> whether the cost of switching is worth it. Many of us spent quite a >> while to learn monotone already, and it's hard to spend time to learn >> something else unless it's clear that there's significant return. Also, >> if we switch to X now, should we switch to Y when that becomes _better_? >> >> Pidgin isn't in the business of developing DVCSs. If monotone becomes >> not good enough, or if there's a clear winner in the DVCS space, then >> ya, maybe it's silly to keep using monotone then. >> >> -khc > > Git must have really improved since we made the switch to monotone. I > did some digging around, and since I am quite nearly an invenerate > pack-rat, I found a working copy of a git repo I created back when we > were evaluating which dvcs to use. The git repo from then is 649M, my > much much newer monotone database is only 244M. > > I recall that the size of a git database was such a problem that the > kernel developers weren't even trying to use a database with an entire > history in it, they dumped all their historical stuff in one repository > and had another with just the 2.6 stuff in it. > > Looking at it now, it appears that their basic work flow is that anytime > someone does significant enough work that someone else might want to > help them with it, before it is merged into the one head, they create a > new download target on git.kernel.org. Though I could be wrong here, > I've spent very little time thinking about git since we made the > decision, and I'm a little foggy on how it works now. > > Still, there are some important things to remember here. We spent > considerable time and effort evaluating our options when we made this > switch. I am a little tired of the idea that we made it relatively > arbitrarily. > > At the time there were a number of apparently equally viable DVCS. I > looked at _all_ of them, including git, bzr. hg, at the time, was not > even used by redhat, and did not appear to be really viable, so I admit > I did not look at it. Of the ones out there, while a fair few had > started implementing subversion -> $dvcs support, only two had _working_ > support, git and monotone. At least, several had support that > _appeared_ like it it _might_ work for much smaller repositories, but > only two could handle _ours_. We wanted to have the full history > available to us. > > Of them, git, at the time, as you claim this is solved, required almost > a full CDs worth of space just for the repository. Unlike monotone, > this repository has to be stored _per working copy_. That means if I am > working on head in pidgin.my/ and gobjectification in pidgin.gobject/ > and 2.4.x in pidgin.2.4/ then I incur this cost 3 times, whereas with > montone I have one database, and so incur the cost once. Monotone > _could_ be larger than a git repo and still be a clear winner (space > wise) on this alone. In fact, this was one of the deciding factors in > picking monotone over git. Several developers expressed a very strong > dis-interest in re-learning their work flows to be able to effecitently > work on multiple projects in one working copy. > > Another consideration is that downloading an ISO's worth of data is, or > at least was, non-trivial for a substantial number of people, again this > was a concerned expressed by some developers at the time. Would you > really consider working on pidgin to contribute that one patch if you > had to download that much just to get going with our DVCS? > > While I have always been attracted to git _because_ it is used by the > kernel developers, and I figure that this fact will ensure that it > continues to be improved on, and ensures that it will continue to have a > substantial body of users who are familiar with it, I really don't think > our choice of monotone was unreasonable given where we were at the time. I asked you before; did you run git-gc? At that time git didn't pack objects automatically, you had to do it yourself, if you didn't the objects where unpacked, loose, taking a lot of space. I've been trying to find at which point packing was introduced, and I've gone as far as 1.0.0 (2005-12-21) and it seems to have been supported since then. Moreover, contributors don't need to download the whole repo, you can have bare clones. You decide the number of commits of depth you need, strictly you only need one commit, which would be the equivalent of a cvs checkout. I'm not saying you didn't spend enough time considering alternatives, maybe you did. But spending time on a task doesn't mean the task is well executed. I find hard to believe that you did a proper job at looking for alternatives because of the result: switch to mtn. I bet other projects considered a SCM switch at the same time, and few, if any, decided to switch to mtn, does that means they made the wrong choice? It's OK to look back and say: I tried hard, but I still made the wrong choice. At best, I would have expected the result to have been; the best is mtn, but it's too early to choose a DSCM. > I wouldn't mind switching now if 1)there were a clear benefit to doing > so and 2)a degree of certainty that we won't be switching again in > another couple years. That being said, I don't think we want to throw > away our work on trac _now_, so we'd want to make sure all the pieces > were in place for trac integration _before_ the switch. For an example of trac using git: http://www.pulseaudio.org/browser -- Felipe Contreras From rekkanoryo@rekkanoryo.org Wed Jul 9 12:33:21 2008 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 09 Jul 2008 12:33:21 -0400 Subject: Monotone analysis In-Reply-To: <20080709113825.GI20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> Message-ID: <4874E851.6090901@rekkanoryo.org> Status: O Content-Length: 1839 Lines: 38 Luke Schierer wrote: > I wouldn't mind switching now if 1)there were a clear benefit to doing > so and 2)a degree of certainty that we won't be switching again in > another couple years. That being said, I don't think we want to throw > away our work on trac _now_, so we'd want to make sure all the pieces > were in place for trac integration _before_ the switch. > > Luke I don't see any reason to switch at all (hmm, deja vu--I recall saying this before the switch to svn). Monotone does everything we need it to and then some. Any extra tools we would gain may make some things easier or nicer, but they're just fluff--they're not *needed* to accomplish any task. I certainly am against a change to ANY VCS or DVCS that doesn't support microbranches in as simple-to-use a manner as mtn does. Microbranches are immensely useful, particularly when trying to introduce a daggy fix, as has been discussed previously. Sure, we do have a few more merges than are strictly necessary, but it's not going to kill us. Ease of use for outsiders isn't that big a deal. We can always make an svn clone of im.pidgin.pidgin public if it's that important to us, but that incurs another maintenance cost that simply isn't worth it. Monotone is not difficult to use, particularly after reading the UsingPidginMonotone wiki page. If people want to complain about the size of the monotone database, I'd suggest they read the previous post in this thread about the size of our old git repo and be thankful mtn is better than that and that git has improved in the meantime. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080709/234854e1/attachment.pgp From rlaager@wiktel.com Wed Jul 9 13:44:10 2008 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 09 Jul 2008 12:44:10 -0500 Subject: Monotone analysis In-Reply-To: <20080709113825.GI20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> Message-ID: <1215625450.18672.9.camel@watermelon.coderich.net> Status: O Content-Length: 1652 Lines: 40 On Wed, 2008-07-09 at 07:38 -0400, Luke Schierer wrote: > Would you really consider working on pidgin to contribute that one > patch if you had to download [an ISO's worth of data] just to get > going with our DVCS? BZR, from what I understand, can do CVS/SVN-style shallow checkouts. They also point out a potential problem with git's shallow checkouts, but I can't speak to that. [1] With regard to git, the issues in [2] would concern me. Obviously, that's a biased page, so I'd be interested to read something from the git folks about that, but I haven't done any searching to find it yet. I found [3] to be an interesting read (it was linked from [1]/[2]). Also, it seems BZR has a feature that I wanted out of Monotone for some time. [4] Richard P.S. I haven't actually used BZR yet, so I'm not really endorsing it here. I'm primarily interested in it because of the Launchpad integration. I'll probably try it out soon with some Debian/Ubuntu packaging work I do. [1] http://bazaar-vcs.org/BzrVsGit#head-4d303353f63ee01ea81b7756170c611a02c3ebf9 [2] http://bazaar-vcs.org/BzrVsGit#head-f8ca6b6d818291c78a38ee10bac6928cd0658042 [3] http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/ [4] ?http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/#comment-221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080709/b0e01259/attachment.pgp From felipe.contreras@gmail.com Wed Jul 9 14:18:57 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Jul 2008 21:18:57 +0300 Subject: Monotone analysis In-Reply-To: <1215625450.18672.9.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <1215625450.18672.9.camel@watermelon.coderich.net> Message-ID: <94a0d4530807091118lbaeaa24k7c5aef12f51842cc@mail.gmail.com> Status: O Content-Length: 2355 Lines: 56 2008/7/9 Richard Laager : > On Wed, 2008-07-09 at 07:38 -0400, Luke Schierer wrote: >> Would you really consider working on pidgin to contribute that one >> patch if you had to download [an ISO's worth of data] just to get >> going with our DVCS? > > BZR, from what I understand, can do CVS/SVN-style shallow checkouts. > They also point out a potential problem with git's shallow checkouts, > but I can't speak to that. [1] >From the documentation: A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. I don't see the problem with that. You would probably want a shallow repository only for patches, or keeping track of the code. > With regard to git, the issues in [2] would concern me. Obviously, > that's a biased page, so I'd be interested to read something from the > git folks about that, but I haven't done any searching to find it yet. It's incredibly biased, I've tried to read it but I don't think it's useful, I just skimmed through it. They are just gathering all possible issues, and even when they found out the issues aren't actually there they just add a note instead of removing the point. About that "robust renaming", they say it breaks under certain conditions, but there's no reference, I don't think it's true. Git automatically finds out if the files are similar enough 50% at least, I think. So you don't need to care about renames ever again, if the file is more than 50% different than the original you can see it as a new file anyway. What happens if you apply a patch that renames a file? There's no problem with git, with bzr you need to be careful I guess. > I found [3] to be an interesting read (it was linked from [1]/[2]). > Also, it seems BZR has a feature that I wanted out of Monotone for some > time. [4] Indeed I agree with most of the points, but these are cosmetics. I have some ideas about how to improve git's index, which is what most people have trouble understanding, hopefully I'll find to implement them. Again, the UI can and will improve, but the underlying design won't change much, that's why I think it's more important. Best regards. -- Felipe Contreras From rlaager@wiktel.com Wed Jul 9 14:26:10 2008 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 09 Jul 2008 13:26:10 -0500 Subject: Monotone analysis In-Reply-To: <1215625450.18672.9.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <1215625450.18672.9.camel@watermelon.coderich.net> Message-ID: <1215627970.18672.25.camel@watermelon.coderich.net> Status: O Content-Length: 1116 Lines: 35 On Wed, 2008-07-09 at 12:44 -0500, Richard Laager wrote: > Also, it seems BZR has a feature that I wanted out of Monotone for > some time. In case anyone is interested, you can replicate this fairly well with the script below--which I put in ~/bin/mtn on my system, where ~/bin comes before /usr/bin in my path. If you don't want to use the PATH manipulation, you can remove that line and replace the calls to mtn with a full path, like /usr/bin/mtn. Richard #!/bin/sh PATH="$(echo "$PATH" | sed "s|$(echo ~/bin):\?||g")" if [ "x$1" != "x" -a "$1" = "commit" ]; then if [ "x$(mtn ls unknown | head -n1)" != "x" ] ; then echo mtn: misuse: unknown changes in working copy >&2 # OPTIONAL: Prints the files. #mtn list unknown | sed "s|^|mtn: misuse: |" >&2 exit 1 fi fi mtn "$@" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080709/0b4ecf5b/attachment.pgp From rlaager@wiktel.com Wed Jul 9 14:35:26 2008 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 09 Jul 2008 13:35:26 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807091118lbaeaa24k7c5aef12f51842cc@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <1215625450.18672.9.camel@watermelon.coderich.net> <94a0d4530807091118lbaeaa24k7c5aef12f51842cc@mail.gmail.com> Message-ID: <1215628526.18672.29.camel@watermelon.coderich.net> Status: O Content-Length: 835 Lines: 20 On Wed, 2008-07-09 at 21:18 +0300, Felipe Contreras wrote: > About that "robust renaming", they say it breaks under certain > conditions, but there's no reference, I don't think it's true. Git > automatically finds out if the files are similar enough 50% at least, > I think. So you don't need to care about renames ever again, if the > file is more than 50% different than the original you can see it as a > new file anyway. Assuming the heuristic you've described is correct, wouldn't that break the history if you changed over 50% of the file? Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080709/82bea1f5/attachment.pgp From felipe.contreras@gmail.com Wed Jul 9 18:37:48 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 01:37:48 +0300 Subject: Monotone analysis In-Reply-To: <1215628526.18672.29.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <1215625450.18672.9.camel@watermelon.coderich.net> <94a0d4530807091118lbaeaa24k7c5aef12f51842cc@mail.gmail.com> <1215628526.18672.29.camel@watermelon.coderich.net> Message-ID: <94a0d4530807091537k414b4e49l6735c70281fba711@mail.gmail.com> Status: O Content-Length: 688 Lines: 18 On Wed, Jul 9, 2008 at 9:35 PM, Richard Laager wrote: > On Wed, 2008-07-09 at 21:18 +0300, Felipe Contreras wrote: >> About that "robust renaming", they say it breaks under certain >> conditions, but there's no reference, I don't think it's true. Git >> automatically finds out if the files are similar enough 50% at least, >> I think. So you don't need to care about renames ever again, if the >> file is more than 50% different than the original you can see it as a >> new file anyway. > > Assuming the heuristic you've described is correct, wouldn't that break > the history if you changed over 50% of the file? Yeah, it's no big deal. -- Felipe Contreras From felipe.contreras@gmail.com Wed Jul 9 19:02:16 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 02:02:16 +0300 Subject: Monotone analysis In-Reply-To: <4874E851.6090901@rekkanoryo.org> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> Message-ID: <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> Status: O Content-Length: 3176 Lines: 67 2008/7/9 John Bailey : > Luke Schierer wrote: >> I wouldn't mind switching now if 1)there were a clear benefit to doing >> so and 2)a degree of certainty that we won't be switching again in >> another couple years. That being said, I don't think we want to throw >> away our work on trac _now_, so we'd want to make sure all the pieces >> were in place for trac integration _before_ the switch. >> >> Luke > > I don't see any reason to switch at all (hmm, deja vu--I recall saying this > before the switch to svn). Monotone does everything we need it to and then > some. Any extra tools we would gain may make some things easier or nicer, but > they're just fluff--they're not *needed* to accomplish any task. > > I certainly am against a change to ANY VCS or DVCS that doesn't support > microbranches in as simple-to-use a manner as mtn does. Microbranches are > immensely useful, particularly when trying to introduce a daggy fix, as has been > discussed previously. Sure, we do have a few more merges than are strictly > necessary, but it's not going to kill us. You can achieve with temporal/topic/local branches what you can achieve with microbranches, except that you have control over what's happening. To me it seems microbranches is a bug renamed to feature; the developers couldn't find a better way to handle the divergence so they just left it there to be solved in the most uncreative way. >From the mtn FAQ: Isn't multiple heads on a branch dangerous or crazy? Monotone takes the approach that divergence is a fundamental part of being a VCS. Divergence always happens. The proper role of a VCS, then, is not to try to prevent or hide divergence, but instead to make it visible and provide tools to manage it. Git/bzr/hg provide better tools to manage the divergence: cheap branches. > Ease of use for outsiders isn't that big a deal. We can always make an svn > clone of im.pidgin.pidgin public if it's that important to us, but that incurs > another maintenance cost that simply isn't worth it. Monotone is not difficult > to use, particularly after reading the UsingPidginMonotone wiki page. If people > want to complain about the size of the monotone database, I'd suggest they read > the previous post in this thread about the size of our old git repo and be > thankful mtn is better than that and that git has improved in the meantime. I am almost sure you didn't pack the git repository, and now you are blaming the size of the repo to git. I calculate that the size of the unpacked repo at that time must have been around 700MB, maybe at that time packing the repo wouldn't be as small as it is today, but certainly not anywhere near 700MB. No one has provided an answer to my question about packing the repo, so I assume nobody did it. Of course MTN isn't hard to use once you get used to it, CVS wasn't either, but once you get used to something superior, you can't go back to the madnes. Would you do serious development in CVS again? Even if a project you want to contribute to is using it and they see no reason to change? There's a reason why nobody is using mtn: it's not ok. -- Felipe Contreras From rekkanoryo@rekkanoryo.org Wed Jul 9 19:34:53 2008 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 9 Jul 2008 18:34:53 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> Message-ID: <20080709233453.GA5375@guifications.org> Status: O Content-Length: 1567 Lines: 39 On Thu, Jul 10, 2008 at 02:02:16AM +0300, Felipe Contreras wrote: > 2008/7/9 John Bailey : > You can achieve with temporal/topic/local branches what you can > achieve with microbranches, except that you have control over what's > happening. I can control what happens in a microbranch just as well as any git, bzr, or hg user can with their branches. > Git/bzr/hg provide better tools to manage the divergence: cheap branches. And monotone branches aren't cheap? Seriously, what are you smoking? > Of course MTN isn't hard to use once you get used to it, CVS wasn't > either, but once you get used to something superior, you can't go back > to the madnes. Would you do serious development in CVS again? Even if > a project you want to contribute to is using it and they see no reason > to change? Yes, I would. CVS may suck, but it does what it does in a predictable and well-known fashion. I do, in fact, still use CVS on occasion. > There's a reason why nobody is using mtn: it's not ok. And again you spout an _opinion_ that you haven't supported with any real, irrefutable evidence. If you want to bitch about monotone, go bitch to its developers. I'm tired of seeing your complaints about our decision on what tool to use. If you can't handle that, tough. John -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080709/268c69a1/attachment.pgp From felipe.contreras@gmail.com Wed Jul 9 20:14:54 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 03:14:54 +0300 Subject: Monotone analysis In-Reply-To: <20080709233453.GA5375@guifications.org> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> Message-ID: <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> Status: O Content-Length: 2833 Lines: 70 On Thu, Jul 10, 2008 at 2:34 AM, John Bailey wrote: > On Thu, Jul 10, 2008 at 02:02:16AM +0300, Felipe Contreras wrote: >> 2008/7/9 John Bailey : >> You can achieve with temporal/topic/local branches what you can >> achieve with microbranches, except that you have control over what's >> happening. > > I can control what happens in a microbranch just as well as any git, > bzr, or hg user can with their branches. You can't decide to drop a commit that somebody else already did, like an applied patch. You can't cleanup the commits somebody else did in his branch before integrating it into your branch. You can't cherry pick commits from a remote branch. In mtn is all or nothing. >> Git/bzr/hg provide better tools to manage the divergence: cheap branches. > > And monotone branches aren't cheap? Seriously, what are you smoking? I have 18 branches in msn-pecan. 12 local and 6 remote. I can reorganize the commits as much as I want locally, move the commits from one branch to another, and then push to the remote branches, nobody has to notice I have local branches. When I'm done I can remove both the local and the remote branches. Adding and removing branches is cheap because a branch is simply a reference to a commit. Creating a branch is creating a one line file, and removing the file removes the branch. In mtn, creating a branch means to add a cert to each and every commit in the branch, while that is not too bad once created, you can't remove it. So you must be careful when you create a branch; it's not cheap. >> Of course MTN isn't hard to use once you get used to it, CVS wasn't >> either, but once you get used to something superior, you can't go back >> to the madnes. Would you do serious development in CVS again? Even if >> a project you want to contribute to is using it and they see no reason >> to change? > > Yes, I would. CVS may suck, but it does what it does in a predictable > and well-known fashion. I do, in fact, still use CVS on occasion. on occasion != serious development. >> There's a reason why nobody is using mtn: it's not ok. > > And again you spout an _opinion_ that you haven't supported with any > real, irrefutable evidence. If you want to bitch about monotone, go > bitch to its developers. I'm tired of seeing your complaints about our > decision on what tool to use. If you can't handle that, tough. I would like to hear another theory about why nobody is using it. Fortunately I don't have to work with such a horrid tool where it's impossible to follow what's happening on a single branch without a diagram, let alone the whole project. And by the way, I don't see why you react so passionately about criticism to the DSCM you are using. It's just a tool, tools can suck. -- Felipe Contreras From lschiere@pidgin.im Wed Jul 9 20:20:21 2008 From: lschiere at pidgin.im (Luke Schierer) Date: Wed, 9 Jul 2008 20:20:21 -0400 Subject: Monotone analysis In-Reply-To: <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> Message-ID: <20080710002021.GJ20474@pidgin.im> Status: O Content-Length: 4502 Lines: 104 On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: > On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: > > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: > >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > >> > = Git recommendation = > >> > >> ?Sure monotone is slower, but is it fast enough? Sure the monotone db is > >> bigger, but is it really that much of a problem? Maybe there are less > >> tools for monotone, but the extra tools for other DVCSs are worthless if > >> we don't plan to use them anyway. > >> > >> While I don't dislike git or anything else, and think that starting with > >> monotone now is a little silly, I think the important thing here is > >> whether the cost of switching is worth it. Many of us spent quite a > >> while to learn monotone already, and it's hard to spend time to learn > >> something else unless it's clear that there's significant return. Also, > >> if we switch to X now, should we switch to Y when that becomes _better_? > >> > >> Pidgin isn't in the business of developing DVCSs. If monotone becomes > >> not good enough, or if there's a clear winner in the DVCS space, then > >> ya, maybe it's silly to keep using monotone then. > >> > >> -khc > > > > Git must have really improved since we made the switch to monotone. I > > did some digging around, and since I am quite nearly an invenerate > > pack-rat, I found a working copy of a git repo I created back when we > > were evaluating which dvcs to use. The git repo from then is 649M, my > > much much newer monotone database is only 244M. > > > > I recall that the size of a git database was such a problem that the > > kernel developers weren't even trying to use a database with an entire > > history in it, they dumped all their historical stuff in one repository > > and had another with just the 2.6 stuff in it. > > > > I asked you before; did you run git-gc? I am sorry, I did not see that question. I did not. > > At that time git didn't pack objects automatically, you had to do it > yourself, if you didn't the objects where unpacked, loose, taking a > lot of space. > > I've been trying to find at which point packing was introduced, and > I've gone as far as 1.0.0 (2005-12-21) and it seems to have been > supported since then. I am unsure when it was introduced, but I've also an old source for git laying around, which indicates I was using 0.99.9h or 0.99.9i, not sure which. Neither have a git-gc available. > > Moreover, contributors don't need to download the whole repo, you can > have bare clones. You decide the number of commits of depth you need, > strictly you only need one commit, which would be the equivalent of a > cvs checkout. shallow clones are indeed interesting. > > I'm not saying you didn't spend enough time considering alternatives, > maybe you did. But spending time on a task doesn't mean the task is > well executed. I find hard to believe that you did a proper job at > looking for alternatives because of the result: switch to mtn. I bet > other projects considered a SCM switch at the same time, and few, if > any, decided to switch to mtn, does that means they made the wrong > choice? as git-gc didn't exist, I'm going to bet that _at that time_, we would have been stuck with the unpacked repository. That means that the objections against git then are just as strong as I've presented them. At the time, as I tried to express, the field was much wider, and the available data on which of the many dscm available would make the best long term choice much sparser. > > It's OK to look back and say: I tried hard, but I still made the wrong choice. > > At best, I would have expected the result to have been; the best is > mtn, but it's too early to choose a DSCM. *shakes head* I'd argue that even the worst of the DSCM is better than subversion or cvs. > > > I wouldn't mind switching now if 1)there were a clear benefit to doing > > so and 2)a degree of certainty that we won't be switching again in > > another couple years. That being said, I don't think we want to throw > > away our work on trac _now_, so we'd want to make sure all the pieces > > were in place for trac integration _before_ the switch. > > For an example of trac using git: > http://www.pulseaudio.org/browser Either way, I am impressed with the results of git-gc, now that it is available. It takes my nearly 700mb repository and reduces it to 44mb. Very impressive. Luke From grim@reaperworld.com Wed Jul 9 20:32:46 2008 From: grim at reaperworld.com (Gary Kramlich) Date: Wed, 09 Jul 2008 19:32:46 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> Message-ID: <487558AE.3060305@reaperworld.com> Status: O Content-Length: 4242 Lines: 107 Felipe Contreras wrote: > On Thu, Jul 10, 2008 at 2:34 AM, John Bailey wrote: >> On Thu, Jul 10, 2008 at 02:02:16AM +0300, Felipe Contreras wrote: >>> 2008/7/9 John Bailey : >>> You can achieve with temporal/topic/local branches what you can >>> achieve with microbranches, except that you have control over what's >>> happening. >> I can control what happens in a microbranch just as well as any git, >> bzr, or hg user can with their branches. > > You can't decide to drop a commit that somebody else already did, like > an applied patch. mutable history isn't an option for us > You can't cleanup the commits somebody else did in his branch before > integrating it into your branch. mutable history isn't an option for us > You can't cherry pick commits from a remote branch. mtn help pluck > In mtn is all or nothing. in mtn we read all the documentation >>> Git/bzr/hg provide better tools to manage the divergence: cheap branches. >> And monotone branches aren't cheap? Seriously, what are you smoking? > > I have 18 branches in msn-pecan. 12 local and 6 remote. I can > reorganize the commits as much as I want locally, move the commits > from one branch to another, and then push to the remote branches, > nobody has to notice I have local branches. When I'm done I can remove > both the local and the remote branches. mtn approve -rDEADBEEF -b im.pidgin.someother branch Look i just copied a commit to another branch. As far as moving goes, mutable history isn't an option for us. Local branches are possible in mtn as well, you never push them. When you want to move all your commits from a local branch to a "remote" branch, propagate and push the remote branch. > Adding and removing branches is cheap because a branch is simply a > reference to a commit. Creating a branch is creating a one line file, > and removing the file removes the branch. A branch is just a cert. When it comes to removing branches, mutable history is not an option for us. > In mtn, creating a branch means to add a cert to each and every commit > in the branch, while that is not too bad once created, you can't > remove it. So you must be careful when you create a branch; it's not > cheap. mutable history isn't an option for us. We *WANT* to know about the branch even if it's not used anymore. >>> Of course MTN isn't hard to use once you get used to it, CVS wasn't >>> either, but once you get used to something superior, you can't go back >>> to the madnes. Would you do serious development in CVS again? Even if >>> a project you want to contribute to is using it and they see no reason >>> to change? >> Yes, I would. CVS may suck, but it does what it does in a predictable >> and well-known fashion. I do, in fact, still use CVS on occasion. > > on occasion != serious development. On occasion can be, damn this app I use every day is consistently crashing, I need to fix it. Which to me, is serious development. >>> There's a reason why nobody is using mtn: it's not ok. >> And again you spout an _opinion_ that you haven't supported with any >> real, irrefutable evidence. If you want to bitch about monotone, go >> bitch to its developers. I'm tired of seeing your complaints about our >> decision on what tool to use. If you can't handle that, tough. > > I would like to hear another theory about why nobody is using it. How's this? People think Linus knows best in every situation? > Fortunately I don't have to work with such a horrid tool where it's > impossible to follow what's happening on a single branch without a > diagram, let alone the whole project. care to elaborate? > And by the way, I don't see why you react so passionately about > criticism to the DSCM you are using. It's just a tool, tools can suck. Passionately... hmm, I thought we were reacting rationally, I'll be sure not to make that mistake again. -- Gary Kramlich -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080709/2a65d4d8/attachment-0001.pgp From felipe.contreras@gmail.com Wed Jul 9 20:33:01 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 03:33:01 +0300 Subject: Monotone analysis In-Reply-To: <20080710002021.GJ20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> Message-ID: <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> Status: O Content-Length: 4903 Lines: 113 On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer wrote: > On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: >> On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: >> > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: >> >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> >> > = Git recommendation = >> >> >> >> ?Sure monotone is slower, but is it fast enough? Sure the monotone db is >> >> bigger, but is it really that much of a problem? Maybe there are less >> >> tools for monotone, but the extra tools for other DVCSs are worthless if >> >> we don't plan to use them anyway. >> >> >> >> While I don't dislike git or anything else, and think that starting with >> >> monotone now is a little silly, I think the important thing here is >> >> whether the cost of switching is worth it. Many of us spent quite a >> >> while to learn monotone already, and it's hard to spend time to learn >> >> something else unless it's clear that there's significant return. Also, >> >> if we switch to X now, should we switch to Y when that becomes _better_? >> >> >> >> Pidgin isn't in the business of developing DVCSs. If monotone becomes >> >> not good enough, or if there's a clear winner in the DVCS space, then >> >> ya, maybe it's silly to keep using monotone then. >> >> >> >> -khc >> > >> > Git must have really improved since we made the switch to monotone. I >> > did some digging around, and since I am quite nearly an invenerate >> > pack-rat, I found a working copy of a git repo I created back when we >> > were evaluating which dvcs to use. The git repo from then is 649M, my >> > much much newer monotone database is only 244M. >> > >> > I recall that the size of a git database was such a problem that the >> > kernel developers weren't even trying to use a database with an entire >> > history in it, they dumped all their historical stuff in one repository >> > and had another with just the 2.6 stuff in it. >> > >> >> I asked you before; did you run git-gc? > > I am sorry, I did not see that question. I did not. > >> >> At that time git didn't pack objects automatically, you had to do it >> yourself, if you didn't the objects where unpacked, loose, taking a >> lot of space. >> >> I've been trying to find at which point packing was introduced, and >> I've gone as far as 1.0.0 (2005-12-21) and it seems to have been >> supported since then. > > I am unsure when it was introduced, but I've also an old source for git > laying around, which indicates I was using 0.99.9h or 0.99.9i, not sure > which. Neither have a git-gc available. git-repack did that. It's explained in tutorial.txt on 0.99.9h. >> Moreover, contributors don't need to download the whole repo, you can >> have bare clones. You decide the number of commits of depth you need, >> strictly you only need one commit, which would be the equivalent of a >> cvs checkout. > > shallow clones are indeed interesting. > >> >> I'm not saying you didn't spend enough time considering alternatives, >> maybe you did. But spending time on a task doesn't mean the task is >> well executed. I find hard to believe that you did a proper job at >> looking for alternatives because of the result: switch to mtn. I bet >> other projects considered a SCM switch at the same time, and few, if >> any, decided to switch to mtn, does that means they made the wrong >> choice? > > as git-gc didn't exist, I'm going to bet that _at that time_, we would > have been stuck with the unpacked repository. That means that the > objections against git then are just as strong as I've presented them. > > At the time, as I tried to express, the field was much wider, and the > available data on which of the many dscm available would make the best > long term choice much sparser. > >> >> It's OK to look back and say: I tried hard, but I still made the wrong choice. >> >> At best, I would have expected the result to have been; the best is >> mtn, but it's too early to choose a DSCM. > > *shakes head* I'd argue that even the worst of the DSCM is better than > subversion or cvs. That's arguable, svn is not so bad. >> >> > I wouldn't mind switching now if 1)there were a clear benefit to doing >> > so and 2)a degree of certainty that we won't be switching again in >> > another couple years. That being said, I don't think we want to throw >> > away our work on trac _now_, so we'd want to make sure all the pieces >> > were in place for trac integration _before_ the switch. >> >> For an example of trac using git: >> http://www.pulseaudio.org/browser > > Either way, I am impressed with the results of git-gc, now that it is > available. It takes my nearly 700mb repository and reduces it to 44mb. > Very impressive. No, the repository back then was much smaller, I think the result would be around 15MB, probably less. -- Felipe Contreras From felipe.contreras@gmail.com Wed Jul 9 21:02:08 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 04:02:08 +0300 Subject: Monotone analysis In-Reply-To: <487558AE.3060305@reaperworld.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> Message-ID: <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> Status: O Content-Length: 5945 Lines: 152 Hi, Regarding the multiple "mutable history is not an option for us". I sent a couple of patches, and I received some comments, so I was expected to modify the patches, isn't that mutating the history? Imagine the patches where in my mtn repository, and somehow I'm able to fix them, and send them again. The maintainers shouldn't care about how the patches where created, just that they are ok. So mutable history is not an option for maintainers, but it is the only option for contributors without commit access, at least when there's reviewing and changes needed. Quoting Linus [1]: "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." On Thu, Jul 10, 2008 at 3:32 AM, Gary Kramlich wrote: > Felipe Contreras wrote: >> On Thu, Jul 10, 2008 at 2:34 AM, John Bailey wrote: >>> On Thu, Jul 10, 2008 at 02:02:16AM +0300, Felipe Contreras wrote: >>>> 2008/7/9 John Bailey : >>>> You can achieve with temporal/topic/local branches what you can >>>> achieve with microbranches, except that you have control over what's >>>> happening. >>> I can control what happens in a microbranch just as well as any git, >>> bzr, or hg user can with their branches. >> >> You can't decide to drop a commit that somebody else already did, like >> an applied patch. > > mutable history isn't an option for us > >> You can't cleanup the commits somebody else did in his branch before >> integrating it into your branch. > > mutable history isn't an option for us > >> You can't cherry pick commits from a remote branch. > > mtn help pluck That's from the same repository. >> In mtn is all or nothing. > > in mtn we read all the documentation I was arguing that you don't have control over what happens. >>>> Git/bzr/hg provide better tools to manage the divergence: cheap branches. >>> And monotone branches aren't cheap? Seriously, what are you smoking? >> >> I have 18 branches in msn-pecan. 12 local and 6 remote. I can >> reorganize the commits as much as I want locally, move the commits >> from one branch to another, and then push to the remote branches, >> nobody has to notice I have local branches. When I'm done I can remove >> both the local and the remote branches. > > mtn approve -rDEADBEEF -b im.pidgin.someother branch > > Look i just copied a commit to another branch. As far as moving goes, > mutable history isn't an option for us. > > Local branches are possible in mtn as well, you never push them. When > you want to move all your commits from a local branch to a "remote" > branch, propagate and push the remote branch. Sure, but a local branch that you can't rebase isn't that helpful. >> Adding and removing branches is cheap because a branch is simply a >> reference to a commit. Creating a branch is creating a one line file, >> and removing the file removes the branch. > > A branch is just a cert. When it comes to removing branches, mutable > history is not an option for us. > >> In mtn, creating a branch means to add a cert to each and every commit >> in the branch, while that is not too bad once created, you can't >> remove it. So you must be careful when you create a branch; it's not >> cheap. > > mutable history isn't an option for us. We *WANT* to know about the > branch even if it's not used anymore. All the commits of the branch are still there, it's just the pointer that disappears. You would see it as a microbranch merge. It's not mutable history. >>>> Of course MTN isn't hard to use once you get used to it, CVS wasn't >>>> either, but once you get used to something superior, you can't go back >>>> to the madnes. Would you do serious development in CVS again? Even if >>>> a project you want to contribute to is using it and they see no reason >>>> to change? >>> Yes, I would. CVS may suck, but it does what it does in a predictable >>> and well-known fashion. I do, in fact, still use CVS on occasion. >> >> on occasion != serious development. > > On occasion can be, damn this app I use every day is consistently > crashing, I need to fix it. Which to me, is serious development. s/serious development/constant contribution/ >>>> There's a reason why nobody is using mtn: it's not ok. >>> And again you spout an _opinion_ that you haven't supported with any >>> real, irrefutable evidence. If you want to bitch about monotone, go >>> bitch to its developers. I'm tired of seeing your complaints about our >>> decision on what tool to use. If you can't handle that, tough. >> >> I would like to hear another theory about why nobody is using it. > > How's this? People think Linus knows best in every situation? That doesn't even make sense. Bazaar is quite popular too and git isn't even maintained by Linus, people disagree with Linus on the git mailing list too. And there's also mercurial. Those are used. >> Fortunately I don't have to work with such a horrid tool where it's >> impossible to follow what's happening on a single branch without a >> diagram, let alone the whole project. > > care to elaborate? I don't have to work with mtn. In other tools you see: merged silly_fix. In mtn you would have to open a visualization tool just to see what the hell that merge 239247130283 into 85938403482 meant. >> And by the way, I don't see why you react so passionately about >> criticism to the DSCM you are using. It's just a tool, tools can suck. > > Passionately... hmm, I thought we were reacting rationally, I'll be sure > not to make that mistake again. I was talking about John Bailey. Best regards. [1] http://kerneltrap.org/Linux/Git_Management -- Felipe Contreras From grim@reaperworld.com Wed Jul 9 21:39:33 2008 From: grim at reaperworld.com (Gary Kramlich) Date: Wed, 09 Jul 2008 20:39:33 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> Message-ID: <48756855.2000808@reaperworld.com> Status: O Content-Length: 5491 Lines: 145 Felipe Contreras wrote: > Hi, > > Regarding the multiple "mutable history is not an option for us". > > I sent a couple of patches, and I received some comments, so I was > expected to modify the patches, isn't that mutating the history? > Imagine the patches where in my mtn repository, and somehow I'm able > to fix them, and send them again. The maintainers shouldn't care about > how the patches where created, just that they are ok. If the patch was provided as a pull from your database that you served via mtn serve for us to grab the revs then yes, there wouldn't be any mutating of history. Since your patch was never in mtn which is the location of the history that shouldn't be mutated, there was no mutation. > So mutable history is not an option for maintainers, but it is the > only option for contributors without commit access, at least when > there's reviewing and changes needed. See above > Quoting Linus [1]: > "a grunt should use 'git rebase' to keep his own work in line. A > technical manager, while he hopefully does some useful work on his > own, should strive to make _others_ do as much work as possible, and > then 'git rebase' is the wrong thing, because it will always make it > harder for the people around you to track your tree and to help you > update your tree." So where do we fall? Are we the grunts or you? Either way doesn't matter, we're all least attempting to do work. The amount of work should not determine which workflows should be used. To me, it sounds like git-rebase was added to shut people up that spaz out when theres too much divergance in the history, and make it look more like a CSCM. >>> You can't cherry pick commits from a remote branch. >> mtn help pluck > > That's from the same repository. Not if you pull the remote branch in, which is how it's supposed to be done in monotone. >>> In mtn is all or nothing. >> in mtn we read all the documentation > > I was arguing that you don't have control over what happens. To clean up commits made by someone else, would be mutating the history. Which as I'm sure you know by now, that is not something we want. >> Local branches are possible in mtn as well, you never push them. When >> you want to move all your commits from a local branch to a "remote" >> branch, propagate and push the remote branch. > > Sure, but a local branch that you can't rebase isn't that helpful. Why is not being able to rebase unhelpful? >> mutable history isn't an option for us. We *WANT* to know about the >> branch even if it's not used anymore. > > All the commits of the branch are still there, it's just the pointer > that disappears. You would see it as a microbranch merge. > > It's not mutable history. So you want to "hide" the history? >> On occasion can be, damn this app I use every day is consistently >> crashing, I need to fix it. Which to me, is serious development. > > s/serious development/constant contribution/ I still disagree. On another project I'm working, we're using svn. I absolutely despise svn, possibly more so than you do mtn (if that's possible). But we're using svn, because it's what everyone else knows and understands. The level of support I don't have to provide more than makes up for having to use what I find a obsolete tool. >>>>> There's a reason why nobody is using mtn: it's not ok. >>>> And again you spout an _opinion_ that you haven't supported with any >>>> real, irrefutable evidence. If you want to bitch about monotone, go >>>> bitch to its developers. I'm tired of seeing your complaints about our >>>> decision on what tool to use. If you can't handle that, tough. >>> I would like to hear another theory about why nobody is using it. >> How's this? People think Linus knows best in every situation? > > That doesn't even make sense. Bazaar is quite popular too and git > isn't even maintained by Linus, people disagree with Linus on the git > mailing list too. And there's also mercurial. Those are used. For the record, that was tongue in cheek. The point I was alluding to, is that I can't believe you're going around telling every project that's not using git to go and use git, or even every project that's using monotone to go and switch to git. But that wouldn't be right either. At any rate, I get it. You have an itch to scratch, you want to work on msn, you don't like mtn. That's fine, luckily plugins can easily be developed out of tree. Or if that's not an option use tailor to export our mtn to git, and if need be, git back to mtn. Or is tailor just another crappy tool? > I don't have to work with mtn. see above > In other tools you see: merged silly_fix. In mtn you would have to > open a visualization tool just to see what the hell that merge > 239247130283 into 85938403482 meant. Right, and when you open said visualization tool, it'll load up everything just once, and look, you have all your history there that saves you're precious 8.5 seconds more that it took to do an mtn merge. > I was talking about John Bailey. So you're trying to make a technical discussion personal, interesting... > Best regards. -- Gary Kramlich -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080709/0c3aee5a/attachment-0001.pgp From rlaager@wiktel.com Wed Jul 9 22:38:15 2008 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 09 Jul 2008 21:38:15 -0500 Subject: Monotone analysis In-Reply-To: <48756855.2000808@reaperworld.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> Message-ID: <1215657495.8474.20.camel@watermelon.coderich.net> Status: O Content-Length: 4005 Lines: 75 On Wed, 2008-07-09 at 20:39 -0500, Gary Kramlich wrote: > I sent a couple of patches, and I received some comments, so I was > > expected to modify the patches, isn't that mutating the history? > > Imagine the patches where in my mtn repository, and somehow I'm able > > to fix them, and send them again. The maintainers shouldn't care about > > how the patches where created, just that they are ok. > > If the patch was provided as a pull from your database that you served > via mtn serve for us to grab the revs Here's how I imagine this working (using Felipe as a hypothetical new contributor and me as the hypothetical developer reviewing his code): 1. Felipe says, "I hate that Pidgin does/doesn't do X. I'm going to fix that. He checks out Pidgin. (Ideally a shallow checkout should be an option.) 2. Felipe writes some rockin' code, committing to a branch he created for the purpose as he goes. This is `vcs commit -b new_branch` initially and `vcs commit` later. 3. He pushes his branch to somewhere like Launchpad, for example. Please don't hate on me if you don't like Launchpad in particular, it's just an example. Launchpad sends an e-mail to people interested in such things (individually subscribed or by team or a mailing list or whatever). I'm one of those people. I click a link to view the diff. (Ideally, it would be against trunk if it merged cleanly, otherwise against the last revision that it merged cleanly against. Super-ideally, it would have done a test compile and I wouldn't have to see it if it didn't compile and pass make check, but we're not there yet.) 4. I like the code, but suggest a few changes (via the web interface or e-mail or whatever). This communication is logged with the branch, sent to Felipe, and it's marked pending or whatever so we know it's been reviewed. 5. Felipe sees my comments and addresses them with code changes. He makes more commits and when he's ready, he pushes again. 6. I get a new notification. I like the changes. I merge the branch to trunk. Now, you'll notice in this work-flow that I only reviewed diffs from trunk at certain states. This is what happened in the past, where people would use cvs diff and mail in a patch. This is in effect what is happening with a git-rebase and a diff. In Monotone, you'd have a propagate and a diff. (For our hypothetical code review service like Launchpad, it could be doing an explicit_merge bisect if the patch didn't apply cleanly.) Anyway, it's all the same effect from a review stand-point, and this is what Linus (and every reviewer) wants (make other people to clean it up as much as possible). However, with a non-mutable history, I can see all the steps in the middle, if I want to see how the code developed. If I don't care, I just don't look at that. Now, once it's merged, if you're looking at branches on trunk, you see the merge, which should have a changelog of something like: "Merge in code from Felipe to do X." The diff from that revision against its parent on trunk is the clean net diff that you'd get from the traditional diff & mail process or from git-rebase. However, all the real history is there as well, if you care to follow the tree up the other parent. Monotone lacks the hosting service and the shallow checkouts. git and bzr, from what I read, have those (though Launchpad is closer to this idea than a generic git host), but they lack a native way to represent things like the test case passing, but I'm not sure that matters (because the hosting service could store that separately anyway). Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080709/75b707df/attachment.pgp From rekkanoryo@rekkanoryo.org Wed Jul 9 23:03:12 2008 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 09 Jul 2008 23:03:12 -0400 Subject: Monotone analysis In-Reply-To: <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> Message-ID: <48757BF0.9080200@rekkanoryo.org> Status: O Content-Length: 2253 Lines: 51 Felipe Contreras wrote: > I would like to hear another theory about why nobody is using it. I personally don't care why "nobody" (according to you) is using it. It works for us. End of story. > Fortunately I don't have to work with such a horrid tool where it's > impossible to follow what's happening on a single branch without a > diagram, let alone the whole project. I've yet to need a diagram to follow any of our branches. It's not difficult. If it's difficult for you, that's not our problem. > And by the way, I don't see why you react so passionately about > criticism to the DSCM you are using. It's just a tool, tools can suck. Tools can suck, yes. No one is debating that. In this case, my opinion is that your understanding of monotone isn't even described by "sucks". I'll state this as simply as I can: Monotone meets our needs and is easily extended for future needs. Micro-branches work for us--we understand them and can actually use them effectively. We made the decision to use monotone long ago, when you were still off somewhere ignoring us. We aren't changing our minds just because you think we made the wrong choice. Ever since you showed back up and started msn-pecan all I've seen out of you are either announcements for new releases of msn-pecan or posts bitching about monotone. We get the point that you don't like monotone. We also get the point that you think we were wrong for choosing it. I don't care. If you can't live with us using the tools of our choice, or at least not bitch about it every five minutes, then I think you need to get the hell out of Dodge. The *only* reason I'm reacting so strongly to your bitching about monotone is that you're doing nothing but wasting our time and bandwidth for garbage we've already said "We don't care" to more times than I can count. Apparently we were too subtle in saying this previously, so there it is in its simplest possible form. This thread is now officially dead to me. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080709/dfaba0fc/attachment.pgp From lschiere@pidgin.im Wed Jul 9 23:36:32 2008 From: lschiere at pidgin.im (Luke Schierer) Date: Wed, 9 Jul 2008 23:36:32 -0400 Subject: Monotone analysis In-Reply-To: <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> Message-ID: <20080710033632.GK20474@pidgin.im> Status: O Content-Length: 5265 Lines: 119 On Thu, Jul 10, 2008 at 03:33:01AM +0300, Felipe Contreras wrote: > On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer wrote: > > On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: > >> On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: > >> > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: > >> >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > >> >> > = Git recommendation = > >> >> > >> >> ?Sure monotone is slower, but is it fast enough? Sure the monotone db is > >> >> bigger, but is it really that much of a problem? Maybe there are less > >> >> tools for monotone, but the extra tools for other DVCSs are worthless if > >> >> we don't plan to use them anyway. > >> >> > >> >> While I don't dislike git or anything else, and think that starting with > >> >> monotone now is a little silly, I think the important thing here is > >> >> whether the cost of switching is worth it. Many of us spent quite a > >> >> while to learn monotone already, and it's hard to spend time to learn > >> >> something else unless it's clear that there's significant return. Also, > >> >> if we switch to X now, should we switch to Y when that becomes _better_? > >> >> > >> >> Pidgin isn't in the business of developing DVCSs. If monotone becomes > >> >> not good enough, or if there's a clear winner in the DVCS space, then > >> >> ya, maybe it's silly to keep using monotone then. > >> >> > >> >> -khc > >> > > >> > Git must have really improved since we made the switch to monotone. I > >> > did some digging around, and since I am quite nearly an invenerate > >> > pack-rat, I found a working copy of a git repo I created back when we > >> > were evaluating which dvcs to use. The git repo from then is 649M, my > >> > much much newer monotone database is only 244M. > >> > > >> > I recall that the size of a git database was such a problem that the > >> > kernel developers weren't even trying to use a database with an entire > >> > history in it, they dumped all their historical stuff in one repository > >> > and had another with just the 2.6 stuff in it. > >> > > >> > >> I asked you before; did you run git-gc? > > > > I am sorry, I did not see that question. I did not. > > > >> > >> At that time git didn't pack objects automatically, you had to do it > >> yourself, if you didn't the objects where unpacked, loose, taking a > >> lot of space. > >> > >> I've been trying to find at which point packing was introduced, and > >> I've gone as far as 1.0.0 (2005-12-21) and it seems to have been > >> supported since then. > > > > I am unsure when it was introduced, but I've also an old source for git > > laying around, which indicates I was using 0.99.9h or 0.99.9i, not sure > > which. Neither have a git-gc available. > > git-repack did that. > > It's explained in tutorial.txt on 0.99.9h. > > >> Moreover, contributors don't need to download the whole repo, you can > >> have bare clones. You decide the number of commits of depth you need, > >> strictly you only need one commit, which would be the equivalent of a > >> cvs checkout. > > > > shallow clones are indeed interesting. > > > >> > >> I'm not saying you didn't spend enough time considering alternatives, > >> maybe you did. But spending time on a task doesn't mean the task is > >> well executed. I find hard to believe that you did a proper job at > >> looking for alternatives because of the result: switch to mtn. I bet > >> other projects considered a SCM switch at the same time, and few, if > >> any, decided to switch to mtn, does that means they made the wrong > >> choice? > > > > as git-gc didn't exist, I'm going to bet that _at that time_, we would > > have been stuck with the unpacked repository. That means that the > > objections against git then are just as strong as I've presented them. > > > > At the time, as I tried to express, the field was much wider, and the > > available data on which of the many dscm available would make the best > > long term choice much sparser. > > > >> > >> It's OK to look back and say: I tried hard, but I still made the wrong choice. > >> > >> At best, I would have expected the result to have been; the best is > >> mtn, but it's too early to choose a DSCM. > > > > *shakes head* I'd argue that even the worst of the DSCM is better than > > subversion or cvs. > > That's arguable, svn is not so bad. > > >> > >> > I wouldn't mind switching now if 1)there were a clear benefit to doing > >> > so and 2)a degree of certainty that we won't be switching again in > >> > another couple years. That being said, I don't think we want to throw > >> > away our work on trac _now_, so we'd want to make sure all the pieces > >> > were in place for trac integration _before_ the switch. > >> > >> For an example of trac using git: > >> http://www.pulseaudio.org/browser > > > > Either way, I am impressed with the results of git-gc, now that it is > > available. It takes my nearly 700mb repository and reduces it to 44mb. > > Very impressive. > > No, the repository back then was much smaller, I think the result > would be around 15MB, probably less. > > -- > Felipe Contreras Um, no, Those numbers *ARE* from a repository from back then. luke From felipe.contreras@gmail.com Thu Jul 10 05:23:09 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 12:23:09 +0300 Subject: Monotone analysis In-Reply-To: <20080710033632.GK20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> <20080710033632.GK20474@pidgin.im> Message-ID: <94a0d4530807100223x109aded7n824be087d93878a4@mail.gmail.com> Status: O Content-Length: 5483 Lines: 122 On Thu, Jul 10, 2008 at 6:36 AM, Luke Schierer wrote: > On Thu, Jul 10, 2008 at 03:33:01AM +0300, Felipe Contreras wrote: >> On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer wrote: >> > On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: >> >> On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: >> >> > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: >> >> >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> >> >> > = Git recommendation = >> >> >> >> >> >> ?Sure monotone is slower, but is it fast enough? Sure the monotone db is >> >> >> bigger, but is it really that much of a problem? Maybe there are less >> >> >> tools for monotone, but the extra tools for other DVCSs are worthless if >> >> >> we don't plan to use them anyway. >> >> >> >> >> >> While I don't dislike git or anything else, and think that starting with >> >> >> monotone now is a little silly, I think the important thing here is >> >> >> whether the cost of switching is worth it. Many of us spent quite a >> >> >> while to learn monotone already, and it's hard to spend time to learn >> >> >> something else unless it's clear that there's significant return. Also, >> >> >> if we switch to X now, should we switch to Y when that becomes _better_? >> >> >> >> >> >> Pidgin isn't in the business of developing DVCSs. If monotone becomes >> >> >> not good enough, or if there's a clear winner in the DVCS space, then >> >> >> ya, maybe it's silly to keep using monotone then. >> >> >> >> >> >> -khc >> >> > >> >> > Git must have really improved since we made the switch to monotone. I >> >> > did some digging around, and since I am quite nearly an invenerate >> >> > pack-rat, I found a working copy of a git repo I created back when we >> >> > were evaluating which dvcs to use. The git repo from then is 649M, my >> >> > much much newer monotone database is only 244M. >> >> > >> >> > I recall that the size of a git database was such a problem that the >> >> > kernel developers weren't even trying to use a database with an entire >> >> > history in it, they dumped all their historical stuff in one repository >> >> > and had another with just the 2.6 stuff in it. >> >> > >> >> >> >> I asked you before; did you run git-gc? >> > >> > I am sorry, I did not see that question. I did not. >> > >> >> >> >> At that time git didn't pack objects automatically, you had to do it >> >> yourself, if you didn't the objects where unpacked, loose, taking a >> >> lot of space. >> >> >> >> I've been trying to find at which point packing was introduced, and >> >> I've gone as far as 1.0.0 (2005-12-21) and it seems to have been >> >> supported since then. >> > >> > I am unsure when it was introduced, but I've also an old source for git >> > laying around, which indicates I was using 0.99.9h or 0.99.9i, not sure >> > which. Neither have a git-gc available. >> >> git-repack did that. >> >> It's explained in tutorial.txt on 0.99.9h. >> >> >> Moreover, contributors don't need to download the whole repo, you can >> >> have bare clones. You decide the number of commits of depth you need, >> >> strictly you only need one commit, which would be the equivalent of a >> >> cvs checkout. >> > >> > shallow clones are indeed interesting. >> > >> >> >> >> I'm not saying you didn't spend enough time considering alternatives, >> >> maybe you did. But spending time on a task doesn't mean the task is >> >> well executed. I find hard to believe that you did a proper job at >> >> looking for alternatives because of the result: switch to mtn. I bet >> >> other projects considered a SCM switch at the same time, and few, if >> >> any, decided to switch to mtn, does that means they made the wrong >> >> choice? >> > >> > as git-gc didn't exist, I'm going to bet that _at that time_, we would >> > have been stuck with the unpacked repository. That means that the >> > objections against git then are just as strong as I've presented them. >> > >> > At the time, as I tried to express, the field was much wider, and the >> > available data on which of the many dscm available would make the best >> > long term choice much sparser. >> > >> >> >> >> It's OK to look back and say: I tried hard, but I still made the wrong choice. >> >> >> >> At best, I would have expected the result to have been; the best is >> >> mtn, but it's too early to choose a DSCM. >> > >> > *shakes head* I'd argue that even the worst of the DSCM is better than >> > subversion or cvs. >> >> That's arguable, svn is not so bad. >> >> >> >> >> > I wouldn't mind switching now if 1)there were a clear benefit to doing >> >> > so and 2)a degree of certainty that we won't be switching again in >> >> > another couple years. That being said, I don't think we want to throw >> >> > away our work on trac _now_, so we'd want to make sure all the pieces >> >> > were in place for trac integration _before_ the switch. >> >> >> >> For an example of trac using git: >> >> http://www.pulseaudio.org/browser >> > >> > Either way, I am impressed with the results of git-gc, now that it is >> > available. It takes my nearly 700mb repository and reduces it to 44mb. >> > Very impressive. >> >> No, the repository back then was much smaller, I think the result >> would be around 15MB, probably less. >> >> -- >> Felipe Contreras > > Um, no, Those numbers *ARE* from a repository from back then. Without packing. -- Felipe Contreras From felipe.contreras@gmail.com Thu Jul 10 05:41:49 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 12:41:49 +0300 Subject: Monotone analysis In-Reply-To: <1215657495.8474.20.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> <1215657495.8474.20.camel@watermelon.coderich.net> Message-ID: <94a0d4530807100241p41242f68y6d7c5c466dc93504@mail.gmail.com> Status: O Content-Length: 5155 Lines: 100 2008/7/10 Richard Laager : > On Wed, 2008-07-09 at 20:39 -0500, Gary Kramlich wrote: >> I sent a couple of patches, and I received some comments, so I was >> > expected to modify the patches, isn't that mutating the history? >> > Imagine the patches where in my mtn repository, and somehow I'm able >> > to fix them, and send them again. The maintainers shouldn't care about >> > how the patches where created, just that they are ok. >> >> If the patch was provided as a pull from your database that you served >> via mtn serve for us to grab the revs > > Here's how I imagine this working (using Felipe as a hypothetical new > contributor and me as the hypothetical developer reviewing his code): > > 1. Felipe says, "I hate that Pidgin does/doesn't do X. I'm going to > fix that. He checks out Pidgin. (Ideally a shallow checkout > should be an option.) > 2. Felipe writes some rockin' code, committing to a branch he > created for the purpose as he goes. This is `vcs commit -b > new_branch` initially and `vcs commit` later. > 3. He pushes his branch to somewhere like Launchpad, for example. > Please don't hate on me if you don't like Launchpad in > particular, it's just an example. Launchpad sends an e-mail to > people interested in such things (individually subscribed or by > team or a mailing list or whatever). I'm one of those people. I > click a link to view the diff. (Ideally, it would be against > trunk if it merged cleanly, otherwise against the last revision > that it merged cleanly against. Super-ideally, it would have > done a test compile and I wouldn't have to see it if it didn't > compile and pass make check, but we're not there yet.) > 4. I like the code, but suggest a few changes (via the web > interface or e-mail or whatever). This communication is logged > with the branch, sent to Felipe, and it's marked pending or > whatever so we know it's been reviewed. > 5. Felipe sees my comments and addresses them with code changes. He > makes more commits and when he's ready, he pushes again. > 6. I get a new notification. I like the changes. I merge the branch > to trunk. > > Now, you'll notice in this work-flow that I only reviewed diffs from > trunk at certain states. This is what happened in the past, where people > would use cvs diff and mail in a patch. This is in effect what is > happening with a git-rebase and a diff. In Monotone, you'd have a > propagate and a diff. (For our hypothetical code review service like > Launchpad, it could be doing an explicit_merge bisect if the patch > didn't apply cleanly.) Anyway, it's all the same effect from a review > stand-point, and this is what Linus (and every reviewer) wants (make > other people to clean it up as much as possible). > > However, with a non-mutable history, I can see all the steps in the > middle, if I want to see how the code developed. If I don't care, I just > don't look at that. > > Now, once it's merged, if you're looking at branches on trunk, you see > the merge, which should have a changelog of something like: "Merge in > code from Felipe to do X." The diff from that revision against its > parent on trunk is the clean net diff that you'd get from the > traditional diff & mail process or from git-rebase. However, all the > real history is there as well, if you care to follow the tree up the > other parent. > > Monotone lacks the hosting service and the shallow checkouts. git and > bzr, from what I read, have those (though Launchpad is closer to this > idea than a generic git host), but they lack a native way to represent > things like the test case passing, but I'm not sure that matters > (because the hosting service could store that separately anyway). Exactly! And bzr also supports rebasing. And both git and bzr support patches natively. So if developers prefer to review patches by mail once you are doing fixing your commits you do git-send-email, or bzr push, and the mails are sent automatically. That is specially useful if the project is using a SCM you don't like. Many people use bzr-svn or git-svn, they work on their favorite tool, and nobody needs to notice you have local branches, and you are reorganizing the commits locally, effectively mutating the history, but only for you. Once the patches are accepted they enter the non-mutable history. What many Pidgin devs don't understand is that people are already mutating the history in mtn with patch reviews, maybe manually, maybe with quilt. The only difference with git/bzr is that this reviewing process can be easier using the SCM tool. And by the way, both git/bzr have quilt like functionality, in the case of bzr through plugins. So yeah, you say you have unmutable history because you leave an important part of the equation out. You can also also do the same with git; never rebase, and use quilt for patch management, except that instead of quilt you can use git, for the maintainer it's the same; he will be receiving patches. Best regards. -- Felipe Contreras From felipe.contreras@gmail.com Thu Jul 10 06:08:16 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 13:08:16 +0300 Subject: Monotone analysis In-Reply-To: <48757BF0.9080200@rekkanoryo.org> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <48757BF0.9080200@rekkanoryo.org> Message-ID: <94a0d4530807100308q64296ef5vbe2a2d1af8529134@mail.gmail.com> Status: O Content-Length: 3940 Lines: 87 On Thu, Jul 10, 2008 at 6:03 AM, John Bailey wrote: > Felipe Contreras wrote: >> I would like to hear another theory about why nobody is using it. > > I personally don't care why "nobody" (according to you) is using it. It works > for us. End of story. http://www.venge.net/mtn-wiki/ProjectsUsingMonotone That list is rather small, with only two important projects there; Pidgin and OpenEmbedded. If you want to say that's an impressive portfolio then fine, for me that's essentially nobody. >> Fortunately I don't have to work with such a horrid tool where it's >> impossible to follow what's happening on a single branch without a >> diagram, let alone the whole project. > > I've yet to need a diagram to follow any of our branches. It's not difficult. > If it's difficult for you, that's not our problem. Compare these: http://developer.pidgin.im/viewmtn/revision/info/99fe11b8da675f3b74b853ea29a16d8c9564cb95 http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=26c1958c322be3ac4dfec9ba2c41c5202bd03709 http://bazaar.launchpad.net/~people-project/people-project/people-trunk/revision/314 See the difference? Only the mtn one has a diagram. That's because when you have a single head per branch you don't need them. The name of the commit is enough to know what's happening (merge from 'atombios'). >> And by the way, I don't see why you react so passionately about >> criticism to the DSCM you are using. It's just a tool, tools can suck. > > Tools can suck, yes. No one is debating that. In this case, my opinion is that > your understanding of monotone isn't even described by "sucks". I've done my best to understand it, I don't think I need to go deeper, I already see many flaws. I've been told that I don't understand mtn, but nobody has told me why. My bet is that because of a few non-relevant misconceptions you want to throw away all my criticism. > I'll state this as simply as I can: > > Monotone meets our needs and is easily extended for future needs. > Micro-branches work for us--we understand them and can actually use them > effectively. We made the decision to use monotone long ago, when you were still > off somewhere ignoring us. We aren't changing our minds just because you think > we made the wrong choice. Ever since you showed back up and started msn-pecan > all I've seen out of you are either announcements for new releases of msn-pecan > or posts bitching about monotone. I've made many suggestions, sent patches, pointed out bugs, and helped people in irc regarding msn issues. Instead of gratitude I only received insults, skepticism about every of my moves. If you apply one of my patches or fix a bug I pointed out are you making me a favor? It's really hard to contribute when nothing I do is ever ok. > We get the point that you don't like monotone. We also get the point that you > think we were wrong for choosing it. I don't care. If you can't live with us > using the tools of our choice, or at least not bitch about it every five > minutes, then I think you need to get the hell out of Dodge. > > The *only* reason I'm reacting so strongly to your bitching about monotone is > that you're doing nothing but wasting our time and bandwidth for garbage we've > already said "We don't care" to more times than I can count. Apparently we were > too subtle in saying this previously, so there it is in its simplest possible form. You can say it as many times as you want it doesn't make it true. Luke already accepted that he didn't run git-repack, and you still argue as if you did a good job at evaluating git; it was written in the tutorial, a visit at #git asking 'why is my repo so huge?', or a post in the mailing list would have pointed out git-repack. In any case, I've seen other developers considering the move, I think you should talk for yourself when you say 'we are not going to switch, period'. -- Felipe Contreras From lschiere@pidgin.im Thu Jul 10 06:32:29 2008 From: lschiere at pidgin.im (Luke Schierer) Date: Thu, 10 Jul 2008 06:32:29 -0400 Subject: Monotone analysis In-Reply-To: <94a0d4530807100223x109aded7n824be087d93878a4@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> <20080710033632.GK20474@pidgin.im> <94a0d4530807100223x109aded7n824be087d93878a4@mail.gmail.com> Message-ID: <20080710103228.GL20474@pidgin.im> Status: O Content-Length: 1529 Lines: 38 On Thu, Jul 10, 2008 at 12:23:09PM +0300, Felipe Contreras wrote: > On Thu, Jul 10, 2008 at 6:36 AM, Luke Schierer wrote: > > On Thu, Jul 10, 2008 at 03:33:01AM +0300, Felipe Contreras wrote: > >> On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer wrote: > >> > On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: > >> >> On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: > >> >> > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: > >> >> >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: > >> >> >> > = Git recommendation = > >> >> > did some digging around, and since I am quite nearly an invenerate > >> >> > pack-rat, I found a working copy of a git repo I created back when we > >> >> > were evaluating which dvcs to use. The git repo from then is 649M, my > >> >> > much much newer monotone database is only 244M. > >> >> > > >> >> I asked you before; did you run git-gc? > >> > > >> > I am sorry, I did not see that question. I did not. > >> > > >> >> > >> > Either way, I am impressed with the results of git-gc, now that it is > >> > available. It takes my nearly 700mb repository and reduces it to 44mb. > >> > Very impressive. > >> > >> No, the repository back then was much smaller, I think the result > >> would be around 15MB, probably less. > >> > >> -- > >> Felipe Contreras > > > > Um, no, Those numbers *ARE* from a repository from back then. > > Without packing. and 44Mb with git-gc. luke From felipe.contreras@gmail.com Thu Jul 10 07:17:31 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 14:17:31 +0300 Subject: Monotone analysis In-Reply-To: <20080710103228.GL20474@pidgin.im> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> <20080710033632.GK20474@pidgin.im> <94a0d4530807100223x109aded7n824be087d93878a4@mail.gmail.com> <20080710103228.GL20474@pidgin.im> Message-ID: <94a0d4530807100417u631ff76qa441e7ee9106d4ca@mail.gmail.com> Status: O Content-Length: 1973 Lines: 48 On Thu, Jul 10, 2008 at 1:32 PM, Luke Schierer wrote: > On Thu, Jul 10, 2008 at 12:23:09PM +0300, Felipe Contreras wrote: >> On Thu, Jul 10, 2008 at 6:36 AM, Luke Schierer wrote: >> > On Thu, Jul 10, 2008 at 03:33:01AM +0300, Felipe Contreras wrote: >> >> On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer wrote: >> >> > On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote: >> >> >> On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer wrote: >> >> >> > On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote: >> >> >> >> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote: >> >> >> >> > = Git recommendation = >> >> >> > did some digging around, and since I am quite nearly an invenerate >> >> >> > pack-rat, I found a working copy of a git repo I created back when we >> >> >> > were evaluating which dvcs to use. The git repo from then is 649M, my >> >> >> > much much newer monotone database is only 244M. >> >> >> > >> >> >> I asked you before; did you run git-gc? >> >> > >> >> > I am sorry, I did not see that question. I did not. >> >> > >> >> >> >> >> > Either way, I am impressed with the results of git-gc, now that it is >> >> > available. It takes my nearly 700mb repository and reduces it to 44mb. >> >> > Very impressive. >> >> >> >> No, the repository back then was much smaller, I think the result >> >> would be around 15MB, probably less. >> >> >> >> -- >> >> Felipe Contreras >> > >> > Um, no, Those numbers *ARE* from a repository from back then. >> >> Without packing. > > and 44Mb with git-gc. Ah, sorry, I was confused, now I see what you meant; it's the actual repository from that time. I think I did a version git clone of your i.p.p that took 15MB... it's weird that the first mtn clone I did was 28MB when the whole i.p.p. was in it, afaik your repo from back then should have less commits than that. -- Felipe Contreras From lschiere@pidgin.im Thu Jul 10 08:02:11 2008 From: lschiere at pidgin.im (Luke Schierer) Date: Thu, 10 Jul 2008 08:02:11 -0400 Subject: Monotone analysis In-Reply-To: <94a0d4530807100417u631ff76qa441e7ee9106d4ca@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <94a0d4530807090604y412490b0h603080be8091eedd@mail.gmail.com> <20080710002021.GJ20474@pidgin.im> <94a0d4530807091733s77da77ccse3fa529c28e391ac@mail.gmail.com> <20080710033632.GK20474@pidgin.im> <94a0d4530807100223x109aded7n824be087d93878a4@mail.gmail.com> <20080710103228.GL20474@pidgin.im> <94a0d4530807100417u631ff76qa441e7ee9106d4ca@mail.gmail.com> Message-ID: <20080710120211.GM20474@pidgin.im> Status: O Content-Length: 479 Lines: 17 > > I think I did a version git clone of your i.p.p that took 15MB... it's > weird that the first mtn clone I did was 28MB when the whole i.p.p. > was in it, afaik your repo from back then should have less commits > than that. > > -- > Felipe Contreras > I suspect that its an artifact of the cleanup Ethan did when he moved us over to monotone, there were some things that imported oddly, which I suspect may have also imported oddly when I did the import to git. Luke From felipe.contreras@gmail.com Thu Jul 10 16:35:26 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 10 Jul 2008 23:35:26 +0300 Subject: Monotone analysis In-Reply-To: <48756855.2000808@reaperworld.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> Message-ID: <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> Status: O Content-Length: 8183 Lines: 203 Hi Gary, On Thu, Jul 10, 2008 at 4:39 AM, Gary Kramlich wrote: > Felipe Contreras wrote: >> Hi, >> >> Regarding the multiple "mutable history is not an option for us". >> >> I sent a couple of patches, and I received some comments, so I was >> expected to modify the patches, isn't that mutating the history? >> Imagine the patches where in my mtn repository, and somehow I'm able >> to fix them, and send them again. The maintainers shouldn't care about >> how the patches where created, just that they are ok. > > If the patch was provided as a pull from your database that you served > via mtn serve for us to grab the revs then yes, there wouldn't be any > mutating of history. Since your patch was never in mtn which is the > location of the history that shouldn't be mutated, there was no mutation. That depends on your definition of history. Is history only the commits that make it into mtn? Is history only the commits that get pulled into the repository of one of the maintainers? >> So mutable history is not an option for maintainers, but it is the >> only option for contributors without commit access, at least when >> there's reviewing and changes needed. > > See above > >> Quoting Linus [1]: >> "a grunt should use 'git rebase' to keep his own work in line. A >> technical manager, while he hopefully does some useful work on his >> own, should strive to make _others_ do as much work as possible, and >> then 'git rebase' is the wrong thing, because it will always make it >> harder for the people around you to track your tree and to help you >> update your tree." > > So where do we fall? Are we the grunts or you? Either way doesn't > matter, we're all least attempting to do work. The amount of work > should not determine which workflows should be used. To me, it sounds > like git-rebase was added to shut people up that spaz out when theres > too much divergance in the history, and make it look more like a CSCM. No, rebasing happens in mtn too, when you review patches and ask for changes, the patch should apply into a head, right?. The only difference is that git provides tools for doing that, while with mtn you are on your own. > > >>>> You can't cherry pick commits from a remote branch. >>> mtn help pluck >> >> That's from the same repository. > > Not if you pull the remote branch in, which is how it's supposed to be > done in monotone. I see. >>>> In mtn is all or nothing. >>> in mtn we read all the documentation >> >> I was arguing that you don't have control over what happens. > > To clean up commits made by someone else, would be mutating the history. > Which as I'm sure you know by now, that is not something we want. Do you always apply patches exactly are they are sent to you? If you do some changes then you are mutating the history, at least according to some definition of 'history'. > > >>> Local branches are possible in mtn as well, you never push them. When >>> you want to move all your commits from a local branch to a "remote" >>> branch, propagate and push the remote branch. >> >> Sure, but a local branch that you can't rebase isn't that helpful. > > Why is not being able to rebase unhelpful? It's helpful, but it's much more helpful to rebase it. With git-rebase you can do more than just rebase. If you do a commit a, and later on you realize that you screwed up, so you do a fix commit a, later on you can do "git rebase --interactive" and squash the two commits into one, you can reorder your commits, edit them, drop them, etc. I can hear you saying again "we don't want mutable history". Let's do a thought experiment. You have the real repo in A, and you have a utility repo in B. In A you have non-mutable history, just like in mtn, in B you have mutable history. You have a temporal branch on B, which you rebase constantly squash commits, re-edit them, reorder, etc. Once you are happy with the commits you would want them into repo A, but if you really think B is tainted since it has mutable history, then you use git to create patches, and you email those patches to yourself, and then you download those patches, and apply them into repo A. Applying patches is not mutating history, right? So git-rebase can be used with repos that don't have mutable history. > > >>> mutable history isn't an option for us. We *WANT* to know about the >>> branch even if it's not used anymore. >> >> All the commits of the branch are still there, it's just the pointer >> that disappears. You would see it as a microbranch merge. >> >> It's not mutable history. > > So you want to "hide" the history? What history? You merged branch "foo" into master, if you remove "foo", all the commits would still be there, the merge would still be there, even the name of the branch would still be there because by default the message of a merge is 'merged foo'. So what is missing? A pointer to "foo" right? But if you are not going to use "foo" anymore what's the point of having it? No history is lost, you can even create the pointer later on if you miss it so much. > > >>> On occasion can be, damn this app I use every day is consistently >>> crashing, I need to fix it. Which to me, is serious development. >> >> s/serious development/constant contribution/ > > I still disagree. On another project I'm working, we're using svn. I > absolutely despise svn, possibly more so than you do mtn (if that's > possible). But we're using svn, because it's what everyone else knows > and understands. The level of support I don't have to provide more than > makes up for having to use what I find a obsolete tool. Perhaps. In any case I personally prefer svn over mtn, even cvs. >>>>>> There's a reason why nobody is using mtn: it's not ok. >>>>> And again you spout an _opinion_ that you haven't supported with any >>>>> real, irrefutable evidence. If you want to bitch about monotone, go >>>>> bitch to its developers. I'm tired of seeing your complaints about our >>>>> decision on what tool to use. If you can't handle that, tough. >>>> I would like to hear another theory about why nobody is using it. >>> How's this? People think Linus knows best in every situation? >> >> That doesn't even make sense. Bazaar is quite popular too and git >> isn't even maintained by Linus, people disagree with Linus on the git >> mailing list too. And there's also mercurial. Those are used. > > For the record, that was tongue in cheek. The point I was alluding to, > is that I can't believe you're going around telling every project that's > not using git to go and use git, or even every project that's using > monotone to go and switch to git. Actually none of the projects I participate in use git, I'm perfectly fine with svn/cvs/bzr. The only tool I can't stand is mtn. > But that wouldn't be right either. At any rate, I get it. You have an > itch to scratch, you want to work on msn, you don't like mtn. That's > fine, luckily plugins can easily be developed out of tree. Or if that's > not an option use tailor to export our mtn to git, and if need be, git > back to mtn. Or is tailor just another crappy tool? Yeah, tailor is crappy. It will create a single branch out of the mtn tree and convert it to git. Just like mtn->svn->git. And even with crappy messages like: [foo-migrate @ whatever]. In case you didn't notice I created a tool that converts a mtn repo into a git repo, preserving all the history: http://pidgin.im/pipermail/devel/2008-June/006125.html >> I don't have to work with mtn. > > see above > >> In other tools you see: merged silly_fix. In mtn you would have to >> open a visualization tool just to see what the hell that merge >> 239247130283 into 85938403482 meant. > > Right, and when you open said visualization tool, it'll load up > everything just once, and look, you have all your history there that > saves you're precious 8.5 seconds more that it took to do an mtn merge. > > > >> I was talking about John Bailey. > > So you're trying to make a technical discussion personal, interesting... No. he seems to take this personally, I was just pointing that out. Cheers. -- Felipe Contreras From grim@reaperworld.com Thu Jul 10 18:50:29 2008 From: grim at reaperworld.com (Gary Kramlich) Date: Thu, 10 Jul 2008 17:50:29 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <1215549919.7566.54.camel@struggle64> <20080709113825.GI20474@pidgin.im> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> Message-ID: <48769235.9000402@reaperworld.com> Status: O Content-Length: 8060 Lines: 190 > Hi Gary, This will be my last response since this thread has gone on far too long and I have other things I *NEED* to be doing. >> If the patch was provided as a pull from your database that you served= >> via mtn serve for us to grab the revs then yes, there wouldn't be any >> mutating of history. Since your patch was never in mtn which is the >> location of the history that shouldn't be mutated, there was no mutati= on. >=20 > That depends on your definition of history. Is history only the > commits that make it into mtn? Is history only the commits that get > pulled into the repository of one of the maintainers? As I was alluding to in my previous post, is that for us, the history is what *IS* _IN_ the monotone db. By your logic, code snipets in irc, or ims, or what have you are considered history, and as far as I know, no tool handles that. > No, rebasing happens in mtn too, when you review patches and ask for > changes, the patch should apply into a head, right?. The only > difference is that git provides tools for doing that, while with mtn > you are on your own. See above. > Do you always apply patches exactly are they are sent to you? If you > do some changes then you are mutating the history, at least according > to some definition of 'history'. I personally will take a contributors patch, commit it with an author cert with their name, and then proceed to do any adjustments with my normal author cert. This is not only important to make sure that the correct credit/blame is given, but is also important if there is concern about the code from a contributor (ie, who has copyright over it, who needs to be contacted in case of license change, etc). >> Why is not being able to rebase unhelpful? >=20 > It's helpful, but it's much more helpful to rebase it. >=20 > With git-rebase you can do more than just rebase. If you do a commit > a, and later on you realize that you screwed up, so you do a fix > commit a, later on you can do "git rebase --interactive" and squash > the two commits into one, you can reorder your commits, edit them, > drop them, etc. >=20 > I can hear you saying again "we don't want mutable history". >=20 > Let's do a thought experiment. You have the real repo in A, and you > have a utility repo in B. In A you have non-mutable history, just like > in mtn, in B you have mutable history. You have a temporal branch on > B, which you rebase constantly squash commits, re-edit them, reorder, > etc. >=20 > Once you are happy with the commits you would want them into repo A, > but if you really think B is tainted since it has mutable history, > then you use git to create patches, and you email those patches to > yourself, and then you download those patches, and apply them into > repo A. >=20 > Applying patches is not mutating history, right? So git-rebase can be > used with repos that don't have mutable history. Don't take this personally, but you're entire example sounds like busy work. If you're revision is trash, you disapprove it with mtn disapprove. This causes divergence, which to me, and I believe the other pidgin developers, is exactly what we want. With that divergence, you have two heads, you then merge them, and essentially squash it. The only difference that I see, is that monotone keeps this history around, and you can't reorder the commits. Both of which I find extremely useful= =2E >> So you want to "hide" the history? >=20 > What history? You merged branch "foo" into master, if you remove > "foo", all the commits would still be there, the merge would still be > there, even the name of the branch would still be there because by > default the message of a merge is 'merged foo'. >=20 > So what is missing? A pointer to "foo" right? But if you are not going > to use "foo" anymore what's the point of having it? No history is > lost, you can even create the pointer later on if you miss it so much. I guess I'm confused here... Since you're "remove" doesn't appear to actually remove anything. Aside for that, I believe theres a difference in terminology here. In monotone you propagate revs from one branch to another. When you propagate, the branch is left working in the event you want to continue to use it. When you're done with it, you suspend the branch, saying that no further development should happen on this branch. When a branch is suspended, it is hidden from mtn ls branches and the automate commands, unless suspended branches are explicitly requested. This is usefully for many reasons. Say you're working on a major API rewrite and have finished a portion of it, and think that it's stable and complete enough for further testing. At that point, you propagate it to im.pidgin.pidgin (or master in git terms) for further testing. However, since theres going to be a lot more breakage, you continue to work on it off of the main branch until you're ready repeat the cycle until the rewrite is complete. > Actually none of the projects I participate in use git, I'm perfectly > fine with svn/cvs/bzr. The only tool I can't stand is mtn. This is find, it's you're prerogative to use/like any tool you choose. However, we like monotone, and see no benefits on switching at this time that outweigh updating all of our tools/scripts/trac/etc as well as having to learn a new SCM. >> But that wouldn't be right either. At any rate, I get it. You have a= n >> itch to scratch, you want to work on msn, you don't like mtn. That's >> fine, luckily plugins can easily be developed out of tree. Or if that= 's >> not an option use tailor to export our mtn to git, and if need be, git= >> back to mtn. Or is tailor just another crappy tool? >=20 > Yeah, tailor is crappy. It will create a single branch out of the mtn > tree and convert it to git. Just like mtn->svn->git. And even with > crappy messages like: [foo-migrate @ whatever]. >=20 > In case you didn't notice I created a tool that converts a mtn repo > into a git repo, preserving all the history: > http://pidgin.im/pipermail/devel/2008-June/006125.html Seems to me, that a lot more people would have benefited if the flaw in tailor had been corrected instead of creating yet another tool, that will probably bit rot due to the authors hatred for monotone. >>> I was talking about John Bailey. >> So you're trying to make a technical discussion personal, interesting.= =2E. >=20 > No. he seems to take this personally, I was just pointing that out. And pointing it out for what reason? The only one I can come up with is that you're looking to either discredit him, humiliate him public, or something else that I can't come up with. What I find really funny here, is that both John and myself have *TRIED* to make things easier for you to work with Pidgin. John even went as far as providing svn mirror of our monotone repository and from what you said above, should have been more than adequate. Now I haven't looked at the logs yet, but I'm willing to bet that it'll show minor usage if an= y. The point I'm getting to here, is that if anyone has a right to be pissed at you, it is John. Creating and maintaining a mirror has a very expensive startup cost. I also know that John tried to setup a git mirror of our monotone as well. And what does he get for it, more bullshit from you and personal attacks. But that's okay, because I'm sure he had nothing better to do... > Cheers. As I said, this is the last you'll hear from me on this topic. Personally, I find the whole thing quite stupid and can't believe I've wasted this much time trying to reach a calm consensus when I should have been doing more important things like writing code and mentoring my summer of code student. --=20 Gary Kramlich -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://pidgin.im/pipermail/devel/attachments/20080710/4bf9644d/attachment.pgp From felipe.contreras@gmail.com Thu Jul 10 19:38:28 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Fri, 11 Jul 2008 02:38:28 +0300 Subject: Monotone analysis In-Reply-To: <48769235.9000402@reaperworld.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> <48769235.9000402@reaperworld.com> Message-ID: <94a0d4530807101638k50e468e2l8e6938b4d266706a@mail.gmail.com> Status: O Content-Length: 10744 Lines: 249 On Fri, Jul 11, 2008 at 1:50 AM, Gary Kramlich wrote: >> Hi Gary, > > This will be my last response since this thread has gone on far too long > and I have other things I *NEED* to be doing. > > > >>> If the patch was provided as a pull from your database that you served= > >>> via mtn serve for us to grab the revs then yes, there wouldn't be any >>> mutating of history. Since your patch was never in mtn which is the >>> location of the history that shouldn't be mutated, there was no mutati= > on. >>=20 >> That depends on your definition of history. Is history only the >> commits that make it into mtn? Is history only the commits that get >> pulled into the repository of one of the maintainers? > > As I was alluding to in my previous post, is that for us, the history is > what *IS* _IN_ the monotone db. By your logic, code snipets in irc, or > ims, or what have you are considered history, and as far as I know, no > tool handles that. Which mtn database? You've said yourself that temporary branches are possible, you just don't push them, are those part of the history? What if I created a patch series from tmp_branch_1, and then after a review fixed them in tmp_branch_2, both are in a mtn db, but I'm sending patches instead of pushing the branches. The commits are there in a mtn db, do they constitute 'history'? Changes are changes; whether they are committed in a maintainer mtn db, in a temporal mtn branch, in patches in the tracker, the mailing list and code snipets in the irc. > > >> No, rebasing happens in mtn too, when you review patches and ask for >> changes, the patch should apply into a head, right?. The only >> difference is that git provides tools for doing that, while with mtn >> you are on your own. > > See above. > > > >> Do you always apply patches exactly are they are sent to you? If you >> do some changes then you are mutating the history, at least according >> to some definition of 'history'. > > I personally will take a contributors patch, commit it with an author > cert with their name, and then proceed to do any adjustments with my > normal author cert. This is not only important to make sure that the > correct credit/blame is given, but is also important if there is concern > about the code from a contributor (ie, who has copyright over it, who > needs to be contacted in case of license change, etc). Fair enough, but not everyone does that. Most of my patches are modified. > > >>> Why is not being able to rebase unhelpful? >>=20 >> It's helpful, but it's much more helpful to rebase it. >>=20 >> With git-rebase you can do more than just rebase. If you do a commit >> a, and later on you realize that you screwed up, so you do a fix >> commit a, later on you can do "git rebase --interactive" and squash >> the two commits into one, you can reorder your commits, edit them, >> drop them, etc. >>=20 >> I can hear you saying again "we don't want mutable history". >>=20 >> Let's do a thought experiment. You have the real repo in A, and you >> have a utility repo in B. In A you have non-mutable history, just like >> in mtn, in B you have mutable history. You have a temporal branch on >> B, which you rebase constantly squash commits, re-edit them, reorder, >> etc. >>=20 >> Once you are happy with the commits you would want them into repo A, >> but if you really think B is tainted since it has mutable history, >> then you use git to create patches, and you email those patches to >> yourself, and then you download those patches, and apply them into >> repo A. >>=20 >> Applying patches is not mutating history, right? So git-rebase can be >> used with repos that don't have mutable history. > > Don't take this personally, but you're entire example sounds like busy > work. If you're revision is trash, you disapprove it with mtn > disapprove. This causes divergence, which to me, and I believe the > other pidgin developers, is exactly what we want. With that divergence, > you have two heads, you then merge them, and essentially squash it. The > only difference that I see, is that monotone keeps this history around, > and you can't reorder the commits. Both of which I find extremely useful= > =2E You missed the point; what you are applying in repo A are patches. A patch series can re reorderd, merged, droped, right? Or suddenly the origin of the patches makes them constitute 'history' and therefore should not be reorderd, merged or dropped? > > >>> So you want to "hide" the history? >>=20 >> What history? You merged branch "foo" into master, if you remove >> "foo", all the commits would still be there, the merge would still be >> there, even the name of the branch would still be there because by >> default the message of a merge is 'merged foo'. >>=20 >> So what is missing? A pointer to "foo" right? But if you are not going >> to use "foo" anymore what's the point of having it? No history is >> lost, you can even create the pointer later on if you miss it so much. > > I guess I'm confused here... Since you're "remove" doesn't appear to > actually remove anything. Aside for that, I believe theres a difference > in terminology here. In monotone you propagate revs from one branch to > another. When you propagate, the branch is left working in the event > you want to continue to use it. When you're done with it, you suspend > the branch, saying that no further development should happen on this > branch. When a branch is suspended, it is hidden from mtn ls branches > and the automate commands, unless suspended branches are explicitly > requested. A branch in git is merely a pointer. When you remove a branch you remove the pointer, not the commits in the branch. You can consider a removed branch a suspended branch, it's hidden. If you want to resume work on that branch you can create a new one, with the same name, pointing to the same commit, so it's exactly the same branch. > This is usefully for many reasons. Say you're working on a major API > rewrite and have finished a portion of it, and think that it's stable > and complete enough for further testing. At that point, you propagate > it to im.pidgin.pidgin (or master in git terms) for further testing. > However, since theres going to be a lot more breakage, you continue to > work on it off of the main branch until you're ready repeat the cycle > until the rewrite is complete. I believe what you call propagate is simply a merge. In git there's no distinction between merging and propagating, it's called merge. If you continue to work on it or not it doesn't matter. > > >> Actually none of the projects I participate in use git, I'm perfectly >> fine with svn/cvs/bzr. The only tool I can't stand is mtn. > > This is find, it's you're prerogative to use/like any tool you choose. > However, we like monotone, and see no benefits on switching at this time > that outweigh updating all of our tools/scripts/trac/etc as well as > having to learn a new SCM. Right. >>> But that wouldn't be right either. At any rate, I get it. You have a= > n >>> itch to scratch, you want to work on msn, you don't like mtn. That's >>> fine, luckily plugins can easily be developed out of tree. Or if that= > 's >>> not an option use tailor to export our mtn to git, and if need be, git= > >>> back to mtn. Or is tailor just another crappy tool? >>=20 >> Yeah, tailor is crappy. It will create a single branch out of the mtn >> tree and convert it to git. Just like mtn->svn->git. And even with >> crappy messages like: [foo-migrate @ whatever]. >>=20 >> In case you didn't notice I created a tool that converts a mtn repo >> into a git repo, preserving all the history: >> http://pidgin.im/pipermail/devel/2008-June/006125.html > > Seems to me, that a lot more people would have benefited if the flaw in > tailor had been corrected instead of creating yet another tool, that > will probably bit rot due to the authors hatred for monotone. I saw the code in tailor, and I tried to improve it, however the design is flawed. Trying to make it replicate the exact topology would require to make it tailor2; a completely different tool. Also, it doesn't even work for the simplistic use-case that it's supposedly supporting right now, at least with git. Besides, there's no reason for such a tool, there are much more effective tools to communicate between git-bzr, git-svn, bzr-git, bzr-svn, git-cvs and bzr-cvs. I don't see the point of tailor. > > >>>> I was talking about John Bailey. >>> So you're trying to make a technical discussion personal, interesting.= > =2E. >>=20 >> No. he seems to take this personally, I was just pointing that out. > > And pointing it out for what reason? The only one I can come up with is > that you're looking to either discredit him, humiliate him public, or > something else that I can't come up with. Surely it wasn't to suggest to don't take it personally, that would be too sensible for me. > What I find really funny here, is that both John and myself have *TRIED* > to make things easier for you to work with Pidgin. John even went as > far as providing svn mirror of our monotone repository and from what you > said above, should have been more than adequate. Now I haven't looked > at the logs yet, but I'm willing to bet that it'll show minor usage if an= > y. Perhaps if it was actually announced in the mailing list or with a link on devel.pidgin.im. I still believe it's useful for people that want to contribute patches. > The point I'm getting to here, is that if anyone has a right to be > pissed at you, it is John. Creating and maintaining a mirror has a very > expensive startup cost. I also know that John tried to setup a git > mirror of our monotone as well. And what does he get for it, more > bullshit from you and personal attacks. But that's okay, because I'm > sure he had nothing better to do... Which personal attacks? I'm grateful for your support and John's, does that means I can't criticize monotone? Again, if I think mtn sucks that has nothing to do with you, or John. >> Cheers. > > As I said, this is the last you'll hear from me on this topic. > Personally, I find the whole thing quite stupid and can't believe I've > wasted this much time trying to reach a calm consensus when I should > have been doing more important things like writing code and mentoring my > summer of code student. Suit yourself, I would have liked for you to understand that rebasing doesn't alter a non-mutable history in exactly the same sense as quilt doesn't. Personally I hope at least some people have learned a thing or two in this discussion, even if they remained silent. Best regards. -- Felipe Contreras From rlaager@wiktel.com Fri Jul 11 11:46:09 2008 From: rlaager at wiktel.com (Richard Laager) Date: Fri, 11 Jul 2008 10:46:09 -0500 Subject: Monotone analysis In-Reply-To: <94a0d4530807101638k50e468e2l8e6938b4d266706a@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <4874E851.6090901@rekkanoryo.org> <94a0d4530807091602k2f746dccs1d50300216fe7b4c@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> <48769235.9000402@reaperworld.com> <94a0d4530807101638k50e468e2l8e6938b4d266706a@mail.gmail.com> Message-ID: <1215791169.9176.13.camel@watermelon.coderich.net> Status: O Content-Length: 2791 Lines: 75 On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote: > A branch in git is merely a pointer. Likewise in MTN. > When you remove a branch you remove the pointer, not the commits in the branch. Likewise. > You can consider a removed branch a suspended branch, it's hidden. If > you want to resume work on that branch you can create a new one, with > the same name, pointing to the same commit, so it's exactly the same > branch. Likewise. > I believe what you call propagate is simply a merge. In git there's no > distinction between merging and propagating, it's called merge. If you > continue to work on it or not it doesn't matter. Likewise in Monotone. You can use explicit_merge if you want. The propagate command is just UI sugar ("porcelain"). mtn propagate $source $dest == mtn explicit_merge h:$source h:$dest $dest \ -m "propagate from branch ..." ?The above are all examples of where you simply don't understand Monotone. I find it funny that you've railed against all the *good* parts of Monotone while missing the actual limitations that the rest of us have pointed out before. If you object to "mtn merge" and "mtn explicit_merge" being separate, I would support suggesting to the Monotone developers that explicit_merge be renamed to merge and if called with no arguments, it assumes arguments based on the current working copy to get the same results as "mtn merge" does now. > I saw the code in tailor, and I tried to improve it, however the > design is flawed. Trying to make it replicate the exact topology would > require to make it tailor2; a completely different tool. From what little I know about it, I'd probably agree. I think they removed the ability to go from a DVCS -> DVCS and keep the structure some time ago (presumably it didn't work well or something). > Also, it > doesn't even work for the simplistic use-case that it's supposedly > supporting right now, at least with git. In my experience (and I realize yours may have differed), it generally works pretty well, as long as you're willing to linearize history completely (which sucks, I agree). > Besides, there's no reason for such a tool, there are much more > effective tools to communicate between git-bzr, git-svn, bzr-git, > bzr-svn, git-cvs and bzr-cvs. I don't see the point of tailor. The point of tailor would be to avoid having to write N^2 tools (one for each pair). I'm not saying that is or isn't achievable or the most efficient way to do things, but that's the design goal. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://pidgin.im/pipermail/devel/attachments/20080711/488679a2/attachment.pgp From felipe.contreras@gmail.com Fri Jul 11 12:36:20 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Fri, 11 Jul 2008 19:36:20 +0300 Subject: Monotone analysis In-Reply-To: <1215791169.9176.13.camel@watermelon.coderich.net> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> <20080709233453.GA5375@guifications.org> <94a0d4530807091714g5838b3e0q8d967e3a519ec5fe@mail.gmail.com> <487558AE.3060305@reaperworld.com> <94a0d4530807091802i23a84242pc24c7c778dfac7f2@mail.gmail.com> <48756855.2000808@reaperworld.com> <94a0d4530807101335u207318c7pe33023607450f2f6@mail.gmail.com> <48769235.9000402@reaperworld.com> <94a0d4530807101638k50e468e2l8e6938b4d266706a@mail.gmail.com> <1215791169.9176.13.camel@watermelon.coderich.net> Message-ID: <94a0d4530807110936o1702e2e0j3cbce42a064e20f@mail.gmail.com> Status: O Content-Length: 2313 Lines: 65 2008/7/11 Richard Laager : > On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote: >> A branch in git is merely a pointer. > > Likewise in MTN. By pointer I meant a single pointer, to a single commit. In mtn a branch is a bunch of commits that have a tag on them, a cert. >> When you remove a branch you remove the pointer, not the commits in the branch. > > Likewise. Except that you can't just drop certs. Once pushed the branches stay there. You can hide them, by adding another cert to the heads, but they stay there. >> You can consider a removed branch a suspended branch, it's hidden. If >> you want to resume work on that branch you can create a new one, with >> the same name, pointing to the same commit, so it's exactly the same >> branch. > > Likewise. > >> I believe what you call propagate is simply a merge. In git there's no >> distinction between merging and propagating, it's called merge. If you >> continue to work on it or not it doesn't matter. > > Likewise in Monotone. You can use explicit_merge if you want. The > propagate command is just UI sugar ("porcelain"). > > mtn propagate $source $dest == > mtn explicit_merge h:$source h:$dest $dest \ > -m "propagate from branch ..." But there's a mental distinction. That's why I used the word "call". I was trying to make clear that the use-case Gary was mentioning was a common usage of branches in git; a merge. > ?The above are all examples of where you simply don't understand > Monotone. Why? Because I assumed branches in mtn are not pointers? (they aren't). Or is it because I said, correctly, that a propagation is a merge? > I find it funny that you've railed against all the *good* parts of > Monotone while missing the actual limitations that the rest of us have > pointed out before. > > If you object to "mtn merge" and "mtn explicit_merge" being separate, I > would support suggesting to the Monotone developers that explicit_merge > be renamed to merge and if called with no arguments, it assumes > arguments based on the current working copy to get the same results as > "mtn merge" does now. That's not a limitation, it's just cosmetics. It would be nice if that gets implemented, but I wouldn't base a choice of SCM based on that. -- Felipe Contreras From jani@ubuntu.com Mon Jul 28 16:55:30 2008 From: jani at ubuntu.com (Jani Monoses) Date: Mon, 28 Jul 2008 23:55:30 +0300 Subject: Monotone analysis In-Reply-To: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: Status: O Content-Length: 867 Lines: 44 Hi Felipe, Thanks a lot for the git mirror, it's a lot easier to check out pidgin than using monotone ( I did that too before finding your mirror) and looking around it (I was not familiar with monotone only with the other 4 major DVCSs :) How often do you update the clone? I see the soc2008.vv branch does not have the last commit from july the 23rd. > > > Perhaps these projects are wrong too[1]: > > * Linux Kernel > * X.org > * Debian (build-tools, debpool, pbuilder) > * Fedora > * GNU autoconf, automake, core-utils > * Compiz Fusion > * PackageKit > * ALSA > * Cairo > * HAL > * D-Bus > * Mesa3D > * OLPC > * Wine > * fluxbox > * Yum > * Ruby on Rails > * Samba > * KVM > * VLC > * x264 > > And recently PulseAudio, and GStreamer is on the way too. And farsight2 uses git instead of darcs which farsight1 uses. thanks Jani From felipe.contreras@gmail.com Mon Jul 28 18:37:52 2008 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 29 Jul 2008 01:37:52 +0300 Subject: Monotone analysis In-Reply-To: References: <94a0d4530807081317i351d1de2v46c7c62c46069610@mail.gmail.com> Message-ID: <94a0d4530807281537n5a21f9d7n547b1e93ba1338f2@mail.gmail.com> Status: O Content-Length: 1271 Lines: 57 Hi Jani, On Mon, Jul 28, 2008 at 11:55 PM, Jani Monoses wrote: > Hi Felipe, > > Thanks a lot for the git mirror, it's a lot easier to check out pidgin > than using monotone ( I did that too before finding your mirror) and > looking around it (I was not familiar with monotone only with the other > 4 major DVCSs :) Good to hear :) I'll cleanup the code so more people can use it. > How often do you update the clone? I see the soc2008.vv branch does not > have the last commit from july the 23rd. I do it randomly. I've been thinking on doing it periodically but nobody mentioned anything... until now. I'll try to do it daily, and today I just updated it. >> >> >> Perhaps these projects are wrong too[1]: >> >> * Linux Kernel >> * X.org >> * Debian (build-tools, debpool, pbuilder) >> * Fedora >> * GNU autoconf, automake, core-utils >> * Compiz Fusion >> * PackageKit >> * ALSA >> * Cairo >> * HAL >> * D-Bus >> * Mesa3D >> * OLPC >> * Wine >> * fluxbox >> * Yum >> * Ruby on Rails >> * Samba >> * KVM >> * VLC >> * x264 >> >> And recently PulseAudio, and GStreamer is on the way too. > > And farsight2 uses git instead of darcs which farsight1 uses. Cool, one more to the list :) Best regards. -- Felipe Contreras From rekkanoryo@rekkanoryo.org Fri Feb 4 23:40:47 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Fri, 04 Feb 2011 23:40:47 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D3A56CB.7050609@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> Message-ID: <4D4CD4CF.5000601@rekkanoryo.org> Status: O Content-Length: 4302 Lines: 91 I apologize in advance for the length of this message. On 01/21/2011 11:02 PM, John Bailey wrote: > This seems like an excellent point at which to summarize again: > > Total votes in favor of hg: 9 > * Developers: 6 > * CPW's: 1 > * Downstream Projects: 2 > > Total votes in favor of git: 3 > * Developers: 3 This debate has dried up. I think it's time to end it. To update everyone, the final votes (with two votes communicated to me off-list) are: Total votes in favor of hg: 11 * Developers: 7 * CPW's: 2 * Downstream Projects: 2 Total votes in favor of git: 5 * Developers: 3 * Downstream Projects: 1 * Translators: 1 (this vote was communicated on the translators@ list) I think it's safe to say hg won. Does anyone disagree with this assessment or object to declaring hg the winner at this point? > Once we're clear on which tool we're going to switch to, we can hash out the > specifics of the conversion (timeline, why I chose to convert in the way I did > when faster methods are available, etc). We really should discuss these points now. Particularly the timeline--when do we want to switch? I assume the answer to that question is "as soon as possible," but begs the question of whether we want to have a blackout on monotone during the entire conversion process or allow commits right up until we're ready to put hg live. I'd like all developers, CPW's, etc. to review the authormap and branchmap files in my hg repository here: http://hg.guifications.org/pidgin-mtn-conv-files/ Any corrections to authormap entries to reflect addresses you'd rather use should be emailed to either Richard or myself, unless you have hg+ssh access to guifications.org already, in which case you can simply commit it yourself. Branch renaming should probably be discussed on-list. Also, as promised I'll explain the choices I made for the hg conversion that have influenced Richard's massive contributions thus far. I chose to use hg's 'convert' extension to convert directly to hg. I *could* have relatively easily used monotone's 'git_export' command and piped it into the hg fast-import extension, but I chose not to do so. Using hg's convert, although slow, allows us to do some history cleanup. Yes, this is modifying our history, but in this case it's for the better. As many of you know, we have a number of revisions in our monotone history that have multiple changelog certs. I've been slowly reviewing these and carefully merging them as best I can to reduce duplication and potential for loss. (This part could be done for a git conversion as well.) As I mentioned previously in this thread, I expanded upon Felipe's prior work on an author map to get consistent author names across our entire history. I've also patched the convert extension to handle comment certs (which monotone's git_export does already) and a new "committer" cert that's come in handy for Richard's extended work. Richard has gone on to take a partial map of our ancient SVN history and use it to set author and committer certs on revisions where a developer committed someone else's patch. The idea here is that our history can now be more accurate with respect to authorship. One unfortunate note here is that hg doesn't directly support a revision whose committer wasn't it's author, which I wasn't aware of until Richard pointed it out. Sure, we can use 'hg commit -u SomeUserName', but there is no revision metadata that says which one of us actually committed the revision. Since no such concept exists in hg to map to, the behavior I've patched into the convert extension adds the committer cert's value to the converted changelog entry. This is consistent with convert's behavior with git conversions and is supported by some tools, such as hgk. To get equivalent behavior out of monotone's git_export command, I'd also have needed to implement a patch. It would have been more difficult to patch monotone's C++ code for the git fast-export stuff than it was to patch convert's python code. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rlaager@wiktel.com Sat Feb 5 00:49:16 2011 From: rlaager at wiktel.com (Richard Laager) Date: Fri, 04 Feb 2011 23:49:16 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D4CD4CF.5000601@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> <4D4CD4CF.5000601@rekkanoryo.org> Message-ID: <1296884956.3610.39.camel@watermelon.coderich.net> Status: O Content-Length: 3352 Lines: 76 On Fri, 2011-02-04 at 23:40 -0500, John Bailey wrote: > I assume the answer to that question is "as soon as > possible," but begs the question of whether we want to have a blackout on > monotone during the entire conversion process or allow commits right up until > we're ready to put hg live. If the incremental mode of the migrate script still works (albeit slower after my changes), I propose the following steps: 0) Have a draft conversion that we're happy with, with the items discussed below complete. 1) Announce a freeze on branch commits that starts in 72 hours. 2) Wait 72 hours. 3) Run the "final conversion". 4) Announce an immediate freeze on i.p.p, assuming no objections in #pidgin or d at c.p.i. (From steps 1-4, people should be pushing pretty quickly after committing on i.p.p.) 5) Run an incremental conversion if there have been commits to i.p.p since step 3. 6) Deploy the hg repository, make MTN read-only, etc. I think the conversion script was taking 36 hours or so to run in full. An incremental run is (I'm just guessing) less than 4 hours. With some time for the cut-over, that means there's a freeze on branch commits for maybe 48 hours and a freeze on trunk commits for 12 hours. > I'd like all developers, CPW's, etc. to review the authormap and branchmap files > in my hg repository here: http://hg.guifications.org/pidgin-mtn-conv-files/ While this should be obvious, it's the portion *after* the = that will be used. Also, if you make changes yourself, keep in mind that you might be listed multiple times. If you're not in the authormap file, check the authormap.TODO file. Those are the people I haven't gotten to identifying yet. (Some of these, especially the ones with a full email, will be trivial to map. I just haven't gone through it all yet.) As a matter of policy, do we want developers to use @pidgin.im email addresses or their "main" addresses? > Richard has gone on to take a partial map of our ancient SVN history and > use it to set author and committer certs on revisions where a developer > committed someone else's patch. In the interest of giving credit where due, almost all of the revision-to-author mapping has come from Felipe. In terms of remaining work, besides the authormap.TODO file, I'd like to go through the history from after the SVN-to-Monotone conversion to identify patch authors. Additionally, we have some author and changelog certs with bad UTF-8. The authors are getting cleaned up as part of the author mapping. The changelog certs have been identified, but John and I haven't done the grunt work of fixing them yet. In terms of remaining questions/issues, I have the following: A) How do we want to handle converting local branches? I think the answer is that people will have to re-run the migrate script on their own computer. While that sucks, it's a one-time pain for very few people. That said, do we know this works? B) I think we need a plan for commit mails, repository serving, and bug tracker integration in place before we cut-over to hg. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rekkanoryo@rekkanoryo.org Sat Feb 5 13:09:55 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Sat, 05 Feb 2011 13:09:55 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <1296884956.3610.39.camel@watermelon.coderich.net> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> <4D4CD4CF.5000601@rekkanoryo.org> <1296884956.3610.39.camel@watermelon.coderich.net> Message-ID: <4D4D9273.7060408@rekkanoryo.org> Status: O Content-Length: 4677 Lines: 94 On 02/05/2011 12:49 AM, Richard Laager wrote: > I think the conversion script was taking 36 hours or so to run in full. > An incremental run is (I'm just guessing) less than 4 hours. With some > time for the cut-over, that means there's a freeze on branch commits for > maybe 48 hours and a freeze on trunk commits for 12 hours. The more I think about this the more I think I'd rather just put a 48-hour freeze on all of mtn and forget about doing an incremental conversion. >> I'd like all developers, CPW's, etc. to review the authormap and branchmap files >> in my hg repository here: http://hg.guifications.org/pidgin-mtn-conv-files/ > > While this should be obvious, it's the portion *after* the = that will > be used. Also, if you make changes yourself, keep in mind that you might > be listed multiple times. The vast majority of developers have at least two authormap entries (I have three, myself). Those of you who had commit access during the CVS/SVN days may have more. > As a matter of policy, do we want developers to use @pidgin.im email > addresses or their "main" addresses? I'd prefer letting each developer choose which address to use. > In terms of remaining work, besides the authormap.TODO file, I'd like to > go through the history from after the SVN-to-Monotone conversion to > identify patch authors. We're going to find quite a few revisions that need fixing up in that respect. I know I've committed a few without setting the author. > Additionally, we have some author and changelog certs with bad UTF-8. > The authors are getting cleaned up as part of the author mapping. The > changelog certs have been identified, but John and I haven't done the > grunt work of fixing them yet. This is another item on my ever-growing TODO list. What puzzles me here is that these revisions don't blow up hg convert. We had a revision with invalid UTF-8 in its changelog cert and that continually blew up the conversion. This is where I started with fixing up the changelog certs. > In terms of remaining questions/issues, I have the following: > > A) How do we want to handle converting local branches? I think the > answer is that people will have to re-run the migrate script on their > own computer. While that sucks, it's a one-time pain for very few > people. That said, do we know this works? The script would need some adaptation for that purpose, as I'm going to try splitting out im.pidgin.www and im.pidgin.web.old into separate mtn dbs so we end up with different hg repos. If someone runs a conversion without splitting these branches out, their hg repo will end up with these branches, and when they push to hg.pidgin.im, all those new revisions would be pushed. This should be possible, though. There may even be some magic argument to convert to make it look only at a given branch for conversion. If worst comes to worst we can hack something together to dump the private branch out of mtn as a series of patches and commit them individually into the hg repo. > B) I think we need a plan for commit mails, repository serving, and bug > tracker integration in place before we cut-over to hg. I can take the stuff from guifications.org for commit mails and ticket auto-closures and adapt it for us. I originally borrwed it from Adium. For repository serving, my intention is to use mercurial-server on one of our servers and hg+ssh for pushes. All we need in this case is an ssh pubkey from every person who gets write access. We can control on (at least) a per-repository level who has write access to what, so we could for example restrict a translator such that (s)he can't create a new repo but can write to an existing one. There is a "root" permission level concept in mercurial-server which gives full access to all repositories served, as well. We would need to determine who should have this permission, as "root" level users can also grant access to other users through the use of an hgadmin repo. For web viewing, hgweb can be set up pretty easily in Apache. I have no idea how difficult it will be in lighttpd. Anonymous clones over http will work through hgweb. There is a trac plugin for hg, as well, but it's only for trac integration. Apparently if you use it with trac 0.12 it can support multiple repositories. I'm not sure about that, as we abandoned trac over at guifications.org in favor of Redmine. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From mark@kingant.net Mon Feb 7 15:50:53 2011 From: mark at kingant.net (Mark Doliner) Date: Mon, 7 Feb 2011 12:50:53 -0800 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D4CD4CF.5000601@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> <4D4CD4CF.5000601@rekkanoryo.org> Message-ID: Status: O Content-Length: 315 Lines: 10 On Fri, Feb 4, 2011 at 8:40 PM, John Bailey wrote: > I think it's safe to say hg won. ?Does anyone disagree with this assessment or > object to declaring hg the winner at this point? I think this is fantastic. Thanks for kicking off this process and tallying the results. --Mark From mark@kingant.net Mon Feb 7 15:51:44 2011 From: mark at kingant.net (Mark Doliner) Date: Mon, 7 Feb 2011 12:51:44 -0800 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D4D9273.7060408@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> <4D4CD4CF.5000601@rekkanoryo.org> <1296884956.3610.39.camel@watermelon.coderich.net> <4D4D9273.7060408@rekkanoryo.org> Message-ID: Status: O Content-Length: 3621 Lines: 77 On Sat, Feb 5, 2011 at 10:09 AM, John Bailey wrote: > On 02/05/2011 12:49 AM, Richard Laager wrote: > >> I think the conversion script was taking 36 hours or so to run in full. >> An incremental run is (I'm just guessing) less than 4 hours. With some >> time for the cut-over, that means there's a freeze on branch commits for >> maybe 48 hours and a freeze on trunk commits for 12 hours. > > The more I think about this the more I think I'd rather just put a 48-hour > freeze on all of mtn and forget about doing an incremental conversion. I think that's totally fine. Whatever is the least amount of work for you. >>> I'd like all developers, CPW's, etc. to review the authormap and branchmap files >>> in my hg repository here: ?http://hg.guifications.org/pidgin-mtn-conv-files/ >> >> While this should be obvious, it's the portion *after* the = that will >> be used. Also, if you make changes yourself, keep in mind that you might >> be listed multiple times. > > The vast majority of developers have at least two authormap entries (I have > three, myself). ?Those of you who had commit access during the CVS/SVN days may > have more. I have this line in authormap.TODO: Mark Doliner = Mark Doliner That can be moved to authormap and changed to: Mark Doliner = Mark Doliner >> As a matter of policy, do we want developers to use @pidgin.im email >> addresses or their "main" addresses? > > I'd prefer letting each developer choose which address to use. +1 >> A) How do we want to handle converting local branches? I think the >> ? ?answer is that people will have to re-run the migrate script on their >> ? ?own computer. While that sucks, it's a one-time pain for very few >> ? ?people. That said, do we know this works? > > The script would need some adaptation for that purpose, as I'm going to try > splitting out im.pidgin.www and im.pidgin.web.old into separate mtn dbs so we > end up with different hg repos. ?If someone runs a conversion without splitting > these branches out, their hg repo will end up with these branches, and when they > push to hg.pidgin.im, all those new revisions would be pushed. > > This should be possible, though. ?There may even be some magic argument to > convert to make it look only at a given branch for conversion. ?If worst comes > to worst we can hack something together to dump the private branch out of mtn as > a series of patches and commit them individually into the hg repo. Another option might be to just force these people to push their stuff to our main repo before the conversion. Or force those people to deal with the problem themselves. I'm not one of those people and I'm pretty cold-hearted, so maybe my vote shouldn't count for much :-) >> B) I think we need a plan for commit mails, repository serving, and bug >> ? ?tracker integration in place before we cut-over to hg. > > I can take the stuff from guifications.org for commit mails and ticket > auto-closures and adapt it for us. ?I originally borrwed it from Adium. Does hg have a standard way to do commit emails, repository serving and bug tracker integration? It seems like it should...? It's not clear to me what you would be borrowing from guifications.org. > For repository serving, my intention is to use mercurial-server on one of our > servers and hg+ssh for pushes. ?All we need in this case is an ssh pubkey from > every person who gets write access. Does that mean we'd need to create a system-wide user account for each commiter? --Mark From felipe.contreras@gmail.com Mon Feb 7 18:52:33 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 01:52:33 +0200 Subject: Moving to Hg without any analysis at all Message-ID: Status: O Content-Length: 1117 Lines: 32 Hi, Last time when I criticized the move to monotone, Luke mentioned this: > We spent considerable time and effort evaluating our options when we made > this switch. I am a little tired of the idea that we made it relatively > arbitrarily. This time there was no analysis at all, there's no list of pros and cons, and no list of reasons why the move to hg is desirable. For posterity, the only reason you have picked hg over the alternatives, is because more people voted for it. People didn't even had to list a reason for their vote, or even cast it publicly. Hopefully you would agree that this time the decision is arbitrary, and you didn't give a chance at all to the alternatives. Given the fact that you have to use monotone right now I can see why you would want to move with haste, but I still think you should _at least_ provide a list of reasons to your community, not just "Because we say so". Cheers. P.S. Please 'reply to all', as I'm not subscribed [1] http://pidgin.im/pipermail/devel/2008-July/006328.html [2] http://pidgin.im/pipermail/devel/2011-February/010135.html -- Felipe Contreras From felipe.contreras@gmail.com Mon Feb 7 19:33:51 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 02:33:51 +0200 Subject: Migration considerations Message-ID: Status: O Content-Length: 4230 Lines: 87 Hi, I saw John Bailey's mail[1] regarding the final (?) decision to move to hg, and I have a few comments. > Also, as promised I'll explain the choices I made for the hg conversion that > have influenced Richard's massive contributions thus far. I chose to use hg's > 'convert' extension to convert directly to hg. I *could* have relatively easily > used monotone's 'git_export' command and piped it into the hg fast-import > extension, but I chose not to do so. Using hg's convert, although slow, allows > us to do some history cleanup. Yes, this is modifying our history, but in this > case it's for the better. I wrote that svn-patch-authors file, and a simple 'git filter-branch' script fixes the authors in no time: https://github.com/felipec/pidgin-git-import/blob/fc-svn-fixes/fix-svn-authors There is no advantage from hg's convert whatsoever. > As many of you know, we have a number of revisions in our monotone history that > have multiple changelog certs. I've been slowly reviewing these and carefully > merging them as best I can to reduce duplication and potential for loss. (This > part could be done for a git conversion as well.) As I mentioned previously in > this thread, I expanded upon Felipe's prior work on an author map to get > consistent author names across our entire history. I've also patched the > convert extension to handle comment certs (which monotone's git_export does > already) and a new "committer" cert that's come in handy for Richard's extended > work. Richard has gone on to take a partial map of our ancient SVN history and > use it to set author and committer certs on revisions where a developer > committed someone else's patch. The idea here is that our history can now be > more accurate with respect to authorship. I wrote that file, as you can see in the hg log. We have been collaborating, if you take a closer look a the pidgin-mtn-conv-files repo you would see that I have contributed a lot of work. > One unfortunate note here is that hg doesn't directly support a revision whose > committer wasn't it's author, which I wasn't aware of until Richard pointed it > out. Sure, we can use 'hg commit -u SomeUserName', but there is no revision > metadata that says which one of us actually committed the revision. Since no > such concept exists in hg to map to, the behavior I've patched into the convert > extension adds the committer cert's value to the converted changelog entry. > This is consistent with convert's behavior with git conversions and is supported > by some tools, such as hgk. In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a patch by me, the s-o-b's would be: Signed-off-by: Felipe Contreras Signed-off-by: John Bailey > To get equivalent behavior out of monotone's git_export command, I'd also have > needed to implement a patch. It would have been more difficult to patch > monotone's C++ code for the git fast-export stuff than it was to patch convert's > python code. No, you could just use 'git filter-branch' as I do in pidgin-git-import. Even if you pick hg, my recommendation woud be to use 'mtn git_export' as I'm confident that tool outputs a correct repo. I wrote a conversion tool in ruby some time ago, and we (Daniel Lenski and I) have spent considerable amount of time making sure that the output is correct. You can then easily convert that to hg. Now, one of the proposals was to provide both git and hg repos, however, it would be great if you store data that can be easily exported to git. 1) Provide both committer and author. Either with Signed-off-by or some other method, but you have to provide both somehow. 2) Always provide valid authors. In git, they are in the form "Real Name ", and the mail part is _mandatory_. If there's no mail address, would make sense. Also, remember that the idea was to start a repository from scratch, so, even if the conversion tool is not finished yet, that doesn't matter as it can always be fixed later on. Cheers. P.S. Again, please 'reply to all' [1] http://pidgin.im/pipermail/devel/2011-February/010135.html -- Felipe Contreras From elb@pidgin.im Mon Feb 7 19:51:52 2011 From: elb at pidgin.im (Ethan Blanton) Date: Mon, 7 Feb 2011 19:51:52 -0500 Subject: Moving to Hg without any analysis at all In-Reply-To: References: Message-ID: <20110208005152.GA7745@colt> Status: O Content-Length: 3563 Lines: 73 I am breaking my policy of not replying to you, and feeding the troll. It is a one-time thing. Felipe Contreras spake unto us the following wisdom: > Last time when I criticized the move to monotone, Luke mentioned this: > > We spent considerable time and effort evaluating our options when we made > > this switch. I am a little tired of the idea that we made it relatively > > arbitrarily. > > This time there was no analysis at all, there's no list of pros and > cons, and no list of reasons why the move to hg is desirable. > > For posterity, the only reason you have picked hg over the > alternatives, is because more people voted for it. People didn't even > had to list a reason for their vote, or even cast it publicly. For posterity ... you're wrong. We *did* discuss pros and cons, at length. We discussed the impact on migration, the loss of information in moving from monotone to hg or git, developers' experiences with hg, git, and other DVCSes which did not make the final cut. We looked at repository sizes and talked about speed. We discussed the differences in branches, tags, naming, etc. in the various systems. We talked about bug tracker integration, both with trac and moving trackers. We even talked about how hilariously wrong your explanations of non-git VCSes are, and how they've not improved since the times when you didn't understand monotone. These discussions took place on mailing lists, on IRC, in the XMPP MUC, in public, in private, and all over the place. You simply weren't present, which was your own choice. Your arguments were heard, and weighed, despite the fact that you interjected them one-sided, misinformed, and late in the process. > Hopefully you would agree that this time the decision is arbitrary, > and you didn't give a chance at all to the alternatives. Given the > fact that you have to use monotone right now I can see why you would > want to move with haste, but I still think you should _at least_ > provide a list of reasons to your community, not just "Because we say > so". We do not. We also are not moving with haste -- we've been discussing this move since before you ever even saw monotone. We have simply decided that the time for a changeover has come, and there is a developer with the energy to do the heavy lifting. Many Pidgin developers have used hg extensively at work, on other open source projects, and on their own time. We (I am included in that group) have considered it very successful at actually *getting things done*. It is fast, it is accurate, it branches and merges cleanly, it runs everywhere, and it is comfortable to use. Those are the reasons we are choosing it. This is not an eternal condemnation of git. Some of us like it very much. We simply aren't choosing to use it for day-to-day Pidgin development. On top of that, most of the work done to perform an hg conversion is required for a git conversion, anyway, due to the fact that git and hg have very similar metadata deficiencies in comparison to mtn -- a conversion from hg to git would be easier than a conversion from mtn to git. Ethan P.S. I see your comments regarding Signed-Off-By:, and using that convention is a good suggestion. It's at least a standard way to work around that particular metadata deficiency. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: Digital signature URL: From lschiere@pidgin.im Mon Feb 7 20:13:25 2011 From: lschiere at pidgin.im (Luke Schierer) Date: Mon, 7 Feb 2011 20:13:25 -0500 Subject: Moving to Hg without any analysis at all In-Reply-To: <20110208005152.GA7745@colt> References: <20110208005152.GA7745@colt> Message-ID: <172A1AE8-0786-478F-8A54-62943E6F63F6@pidgin.im> Status: O Content-Length: 3486 Lines: 51 On Feb 7, 2011, at 19:51 EST, Ethan Blanton wrote: > I am breaking my policy of not replying to you, and feeding the troll. > It is a one-time thing. > > Felipe Contreras spake unto us the following wisdom: >> Last time when I criticized the move to monotone, Luke mentioned this: >>> We spent considerable time and effort evaluating our options when we made >>> this switch. I am a little tired of the idea that we made it relatively >>> arbitrarily. >> >> This time there was no analysis at all, there's no list of pros and >> cons, and no list of reasons why the move to hg is desirable. >> >> For posterity, the only reason you have picked hg over the >> alternatives, is because more people voted for it. People didn't even >> had to list a reason for their vote, or even cast it publicly. > > > This is not an eternal condemnation of git. Some of us like it very > much. We simply aren't choosing to use it for day-to-day Pidgin > development. On top of that, most of the work done to perform an hg > conversion is required for a git conversion, anyway, due to the fact > that git and hg have very similar metadata deficiencies in comparison > to mtn -- a conversion from hg to git would be easier than a > conversion from mtn to git. > A particularly telling point for me as we discussed it was looking at the availability, stability, and maturity of clients on the various platforms we used. It was a particular area where developers seemed, to me, to express more confidence in HG, over git, at the same time expressing that this is indeed likely to be a difference between the two systems that will not persist indefinitely. I also saw, as it was discussed, a number of developers chime in with their real life experiences with both systems, and some give and take as to which of those experiences validly reflect accurate understandings of the two. Particularly, I saw _at least_ 4 emails responding to Felipe's ideas and concerns, including some research done by a developer in github (I think it was github) to be sure that we all had an accurate understanding of git. My inbox shows 30+ emails on the topic, over more than 15 days. The topic is introduced to the mailing list in a way that makes it clear to me that the discussion in fact started, no doubt in either irc or in the muc conference room, sometime prior to that. I see participation from most if not all of the active developers, and even a few, like myself, who are inactive but still interested. I cannot accept that this is in any way a hurried or arbitrary decision. If _any_ developer, cpw, or summer of code contributor felt that there was more to be discussed, concerns not yet considered, I am equally confident that any migration would not be considered final until some sort of consensus had been reached. That being said, I feel like the ballot we held _is_ a valid way of determining that a consensus _has_ been reached. The balloting happened over the mailing list, or I'd not have known about it, and the mailing list cannot in any way shape or form be considered deciding in secret or in private. Luke > Ethan > > P.S. I see your comments regarding Signed-Off-By:, and using that > convention is a good suggestion. It's at least a standard way > to work around that particular metadata deficiency. > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel From rlaager@wiktel.com Mon Feb 7 20:52:16 2011 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 07 Feb 2011 19:52:16 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: <20110208005152.GA7745@colt> References: <20110208005152.GA7745@colt> Message-ID: <1297129936.3795.4.camel@watermelon.coderich.net> Status: O Content-Length: 1166 Lines: 25 On Mon, 2011-02-07 at 19:51 -0500, Ethan Blanton wrote: > P.S. I see your comments regarding Signed-Off-By:, and using that > convention is a good suggestion. It's at least a standard way > to work around that particular metadata deficiency. Unfortunately, the hg tools that support anything seem to use a convention of looking for "committer:" lines. I'd say that if we care about them, we should patch those tools to look for either a committer: line or the top Signed-off-by: line (assuming they don't, of course). I stand by the conversion process using "committer:" and also support us adopting a convention of using "Signed-off-by" for the same reason: the convention with Signed-off-by in Linux is that you are agreeing to the "Developer's Certificate of Origin". So we shouldn't fake those for historical commits, but I'd love to see us start using them. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rlaager@wiktel.com Mon Feb 7 21:09:54 2011 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 07 Feb 2011 20:09:54 -0600 Subject: Migration considerations In-Reply-To: References: Message-ID: <1297130994.3795.21.camel@watermelon.coderich.net> Status: O Content-Length: 2429 Lines: 58 On Tue, 2011-02-08 at 02:33 +0200, Felipe Contreras wrote: > > One unfortunate note here is that hg doesn't directly support a revision whose > > committer wasn't it's author > In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a > patch by me, the s-o-b's would be: > > Signed-off-by: Felipe Contreras > Signed-off-by: John Bailey For the list archive... This is NOT how this is handled in git. This is inline metadata (part of the commit message). It's a Linux convention, not part of git. In other words, git doesn't require Signed-off-by lines, and I could use Signed-off-by lines with version control systems other than git. In git, the author and committer are both tracked as first-class fields: git show --pretty=full HEAD | head -n3 Mercurial has only one field, so we would be forced to track this via something inline like Signed-off-by tags. This is a disadvantage of Mercurial. > > To get equivalent behavior out of monotone's git_export command, I'd also have > > needed to implement a patch. It would have been more difficult to patch > > monotone's C++ code for the git fast-export stuff than it was to patch convert's > > python code. > > No, you could just use 'git filter-branch' as I do in pidgin-git-import. ... from earlier... > There is no advantage from hg's convert whatsoever. The fact that we avoid using a third version control system in the middle is arguably an advantage. That said, `hg convert`'s (lack of) speed is a disadvantage, albeit minor since it only needs to be run once. If you'd like to improve the migration process, I'll certainly accept patches, as you know. > 2) Always provide valid authors. In git, they are in the form "Real Name > ", and the mail part is _mandatory_. If there's no mail > address, would make sense. You're asking us to put fake data into our repository. I don't know why we'd want to do that. Since git requires it, why not just add it as part of the hg -> git conversion, if and only if a revision's author doesn't contain /<.*>/? Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rekkanoryo@rekkanoryo.org Mon Feb 7 21:43:48 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Mon, 7 Feb 2011 21:43:48 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> <4D4CD4CF.5000601@rekkanoryo.org> <1296884956.3610.39.camel@watermelon.coderich.net> <4D4D9273.7060408@rekkanoryo.org> Message-ID: <20110208024347.GA14134@rekkanoryo.org> Status: O Content-Length: 2298 Lines: 48 On Mon, Feb 07, 2011 at 12:51:44PM -0800, Mark Doliner typed: > Another option might be to just force these people to push their stuff > to our main repo before the conversion. Or force those people to deal > with the problem themselves. I'm not one of those people and I'm > pretty cold-hearted, so maybe my vote shouldn't count for much :-) I also don't have this problem. But I know we had a few people who had local patches back in the CVS and SVN days that they wanted to carry over, so surely a few people have local stuff in mtn as well. (I'd hope this is committed, since mtn *is* a DVCS!) > > I can take the stuff from guifications.org for commit mails and ticket > > auto-closures and adapt it for us. ?I originally borrwed it from Adium. > > Does hg have a standard way to do commit emails, repository serving > and bug tracker integration? It seems like it should...? It's not > clear to me what you would be borrowing from guifications.org. Yes, there are standard hooks for commit mails. Trac integration was a pain, as there was no included hook and I had to bisect to find a working revision of the hook script once I found an external one. The trac integration may need some tweaking to get our milestone auto-set done, but that shouldn't be too much trouble. My bit with borrowing from guifications.org is mainly using it as reference to remember what I set up, since it's been a while. We'll also surely want this stuff to be global on pidign.im. We wanted it per-repo for guifications, as we have many more repos than we want commit mails and trac integration for. > > For repository serving, my intention is to use mercurial-server on one of our > > servers and hg+ssh for pushes. ?All we need in this case is an ssh pubkey from > > every person who gets write access. > > Does that mean we'd need to create a system-wide user account for each commiter? No. We'd have one system user account. All permissions are determined by the ssh key in use and the permissions granted in the configuration. John -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From felipe.contreras@gmail.com Mon Feb 7 22:57:23 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 05:57:23 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: <20110208005152.GA7745@colt> References: <20110208005152.GA7745@colt> Message-ID: Status: O Content-Length: 5396 Lines: 115 On Tue, Feb 8, 2011 at 2:51 AM, Ethan Blanton wrote: > Felipe Contreras spake unto us the following wisdom: >> Last time when I criticized the move to monotone, Luke mentioned this: >> > We spent considerable time and effort evaluating our options when we made >> > this switch. I am a little tired of the idea that we made it relatively >> > arbitrarily. >> >> This time there was no analysis at all, there's no list of pros and >> cons, and no list of reasons why the move to hg is desirable. >> >> For posterity, the only reason you have picked hg over the >> alternatives, is because more people voted for it. People didn't even >> had to list a reason for their vote, or even cast it publicly. > > For posterity ... you're wrong. ?We *did* discuss pros and cons, at > length. ?We discussed the impact on migration, the loss of information > in moving from monotone to hg or git, developers' experiences with hg, > git, and other DVCSes which did not make the final cut. ?We looked at > repository sizes and talked about speed. ?We discussed the differences > in branches, tags, naming, etc. in the various systems. ?We talked > about bug tracker integration, both with trac and moving trackers. ?We > even talked about how hilariously wrong your explanations of non-git > VCSes are, and how they've not improved since the times when you > didn't understand monotone. Easy to say. The only recorded "discussion" was between me and John Bailey, which he abandoned after I provided strong arguments against his notion of "branch". And whatever you said about me not understanding monotone was probably behind doors, and wrong, as nobody has every provided evidence of me not understanding something about monotone... not that it matters. And what I said about non-git VCSes still stands. Now, the issue is not that you discussed (without hardly any record), the issue is that there is no conclusion. There's no analysis anywhere. There's no list of pros and cons. There's no list reasons. All those are probably on your mind, and it's hard to counter argue with those. Why don't you provide an analysis? Some official explanation? http://code.google.com/p/support/wiki/DVCSAnalysis > These discussions took place on mailing lists, on IRC, in the XMPP > MUC, in public, in private, and all over the place. ?You simply > weren't present, which was your own choice. ?Your arguments were > heard, and weighed, despite the fact that you interjected them > one-sided, misinformed, and late in the process. _My_ choice? You have banned me from the IRC channel. And I am looking at the online mail archive. There's hardly anything there. >> Hopefully you would agree that this time the decision is arbitrary, >> and you didn't give a chance at all to the alternatives. Given the >> fact that you have to use monotone right now I can see why you would >> want to move with haste, but I still think you should _at least_ >> provide a list of reasons to your community, not just "Because we say >> so". > > We do not. ?We also are not moving with haste -- we've been discussing > this move since before you ever even saw monotone. ?We have simply > decided that the time for a changeover has come, and there is a > developer with the energy to do the heavy lifting. > > Many Pidgin developers have used hg extensively at work, on other open > source projects, and on their own time. ?We (I am included in that > group) have considered it very successful at actually *getting things > done*. ?It is fast, it is accurate, it branches and merges cleanly, it > runs everywhere, and it is comfortable to use. ?Those are the reasons > we are choosing it. git is also fast, accurate, branches and merges cleanly, it runs everywhere, and is comfortable to use. What you are basically saying is: monotone the tool we know, and we are comfortable with. So, again, you are not giving it a chance to anything else. > This is not an eternal condemnation of git. ?Some of us like it very > much. ?We simply aren't choosing to use it for day-to-day Pidgin > development. Yeah, but nobody has said why. No analysis, halted discussions, just counting hands. > On top of that, most of the work done to perform an hg > conversion is required for a git conversion, anyway, due to the fact > that git and hg have very similar metadata deficiencies in comparison > to mtn -- a conversion from hg to git would be easier than a > conversion from mtn to git. Huh? The mtn to git conversion is natively supported by monotone, and there has been a git clone of the mtn repo for years. I have been spent a long long time on it. I developed my own script (mtn2git), and I helped developed the 'mtn git_export' tool, making sure the tree is exactly the same. I wrote tools to find out missing authors. I searched for all the missing information of the authors, and made sure the mapping was up-to-date. And finally, I spent days finding out the authors of the patches from the SVN days. All this was available first on my pidgin-git-import scripts, and later on pidgin-mtn-conv-files. Now I am writing a script to fix the changelogs based on the work on pidgin-mtn-conv-files; it's basically done. I say it's the other way around; it's easier to first convert to git, and then to hg. Has anyone even checked that the output is correct? Same graph? Correct dates? etc. Cheers. -- Felipe Contreras From evan.s@dreskin.net Mon Feb 7 23:05:22 2011 From: evan.s at dreskin.net (Evan Schoenberg, M.D.) Date: Mon, 7 Feb 2011 22:05:22 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> Message-ID: <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Status: O Content-Length: 303 Lines: 12 On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: > What you are basically saying is: monotone the tool we know, and we > are comfortable with This is a perfectly good reason, by itself, when combined with "and monotone can do the job we want it to do." Time is our most precious asset. -Evan From felipe.contreras@gmail.com Mon Feb 7 23:08:57 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 06:08:57 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: <172A1AE8-0786-478F-8A54-62943E6F63F6@pidgin.im> References: <20110208005152.GA7745@colt> <172A1AE8-0786-478F-8A54-62943E6F63F6@pidgin.im> Message-ID: Status: O Content-Length: 4088 Lines: 64 On Tue, Feb 8, 2011 at 3:13 AM, Luke Schierer wrote: > On Feb 7, 2011, at 19:51 EST, Ethan Blanton wrote: >> I am breaking my policy of not replying to you, and feeding the troll. >> It is a one-time thing. >> >> Felipe Contreras spake unto us the following wisdom: >>> Last time when I criticized the move to monotone, Luke mentioned this: >>>> We spent considerable time and effort evaluating our options when we made >>>> this switch. I am a little tired of the idea that we made it relatively >>>> arbitrarily. >>> >>> This time there was no analysis at all, there's no list of pros and >>> cons, and no list of reasons why the move to hg is desirable. >>> >>> For posterity, the only reason you have picked hg over the >>> alternatives, is because more people voted for it. People didn't even >>> had to list a reason for their vote, or even cast it publicly. >> >> > >> This is not an eternal condemnation of git. ?Some of us like it very >> much. ?We simply aren't choosing to use it for day-to-day Pidgin >> development. ?On top of that, most of the work done to perform an hg >> conversion is required for a git conversion, anyway, due to the fact >> that git and hg have very similar metadata deficiencies in comparison >> to mtn -- a conversion from hg to git would be easier than a >> conversion from mtn to git. >> > > A particularly telling point for me as we discussed it was looking at the availability, stability, and maturity of clients on the various platforms we used. ?It was a particular area where developers seemed, to me, to express more confidence in HG, over git, at the same time expressing that this is indeed likely to be a difference between the two systems that will not persist indefinitely. ?I also saw, as it was discussed, a number of developers chime in with their real life experiences with both systems, and some give and take as to which of those experiences validly reflect accurate understandings of the two. ?Particularly, I saw _at least_ 4 emails responding to Felipe's ideas and concerns, including some research done by a developer in github (I think it was github) to be sure that we all had an accurate understanding of git. > > My inbox shows 30+ emails on the topic, over more than 15 days. ?The topic is introduced to the mailing list in a way that makes it clear to me that the discussion in fact started, no doubt in either irc or in the muc conference room, sometime prior to that. ?I see participation from most if not all of the active developers, and even a few, like myself, who are inactive but still interested. > > I cannot accept that this is in any way a hurried or arbitrary decision. ? If _any_ developer, cpw, or summer of code contributor felt that there was more to be discussed, concerns not yet considered, I am equally confident that any migration would not be considered final until some sort of consensus had been reached. This is what I mean by analysis: http://code.google.com/p/support/wiki/DVCSAnalysis There's nothing like that. I have read all the mail archives, and I haven't seen a _single_ reason why hg was preferred over git. The closest was that John Bailey doesn't like git branches, but when I explained why git branches actually make more sense, John conveniently decided to stop the discussion. http://pidgin.im/pipermail/devel/2011-January/010108.html So no, I don't think the possibility of using git has actually been considered at all. > That being said, I feel like the ballot we held _is_ a valid way of determining that a consensus _has_ been reached. ?The balloting happened over the mailing list, or I'd not have known about it, and the mailing list cannot in any way shape or form be considered deciding in secret or in private. Consensus, yes. Explanation, no. In fact, most of the votes were casted _before_ the discussion even finished, many before it even started. It's like no analysis was needed. Read John's mail (with two votes communicated to me off-list): http://pidgin.im/pipermail/devel/2011-February/010135.html -- Felipe Contreras From rekkanoryo@rekkanoryo.org Mon Feb 7 23:13:15 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Mon, 07 Feb 2011 23:13:15 -0500 Subject: Moving to Hg without any analysis at all In-Reply-To: <172A1AE8-0786-478F-8A54-62943E6F63F6@pidgin.im> References: <20110208005152.GA7745@colt> <172A1AE8-0786-478F-8A54-62943E6F63F6@pidgin.im> Message-ID: <4D50C2DB.2060704@rekkanoryo.org> Status: O Content-Length: 2529 Lines: 37 On 02/07/2011 08:13 PM, Luke Schierer wrote: > My inbox shows 30+ emails on the topic, over more than 15 days. The topic is introduced to the mailing list in a way that makes it clear to me that the discussion in fact started, no doubt in either irc or in the muc conference room, sometime prior to that. I see participation from most if not all of the active developers, and even a few, like myself, who are inactive but still interested. This discussion indeed started in the XMPP MUC. I have expressed a desire to move to hg since Gary and I moved to it on guifications.org, which has been well over a year ago. By now it might actually be two years. The general consensus was always "yeah, it'd be nice," with the exception of Ethan, who was always in favor, provided he did not have to do any of the work. As Richard and I have been doing most of the work (and at this point, Richard's contributions outweigh mine), Ethan's completely off the hook there. > I cannot accept that this is in any way a hurried or arbitrary decision. If _any_ developer, cpw, or summer of code contributor felt that there was more to be discussed, concerns not yet considered, I am equally confident that any migration would not be considered final until some sort of consensus had been reached. This is correct. If you re-read some of my more prominent messages in the thread, you'll see that I have on more than one occasion solicited opinions and asked if there were objections. At this point, my opinion is that if an active or recent developer/CPW/SoC student felt there was a need for more discussion but did not initiate it, it's their his damn fault and he can forever hold his peace. > That being said, I feel like the ballot we held _is_ a valid way of determining that a consensus _has_ been reached. The balloting happened over the mailing list, or I'd not have known about it, and the mailing list cannot in any way shape or form be considered deciding in secret or in private. I will grant that the last two votes I accepted (Eion and Kevin) were communicated to me off-list. In that respect, the voting wasn't completely transparent. However, I suspect that both individuals would willingly affirm that they communicated pro-hg votes to me. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From felipe.contreras@gmail.com Mon Feb 7 23:24:21 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 06:24:21 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 1082 Lines: 29 On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. wrote: > > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: > >> What you are basically saying is: monotone the tool we know, and we >> are comfortable with > > This is a perfectly good reason, by itself, when combined with "and monotone can do the job we want it to do." ?Time is our most precious asset. Ah, some honesty. That's all I'm saying; if you don't want to do a careful analysis, fine, just say so. If mercurial turns out not to be the best choice, don't claim you did a careful analysis, because there isn't any. And yeah, that's a perfectly good reason... for a weekend project. I still maintain that the last analysis (that resulted in monotone chosen as the tool) was not done correctly (the main argument was the big space, and nobody bothered to ask how to reduce it; git-repack), and back at that time people said that before choosing another tool, a careful analysis would need to be done, so that the right tool is picked. I guess talk is cheap. Cheers. -- Felipe Contreras From felipe.contreras@gmail.com Mon Feb 7 23:42:43 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 06:42:43 +0200 Subject: Migration considerations In-Reply-To: <1297130994.3795.21.camel@watermelon.coderich.net> References: <1297130994.3795.21.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 2369 Lines: 60 On Tue, Feb 8, 2011 at 4:09 AM, Richard Laager wrote: > On Tue, 2011-02-08 at 02:33 +0200, Felipe Contreras wrote: >> > One unfortunate note here is that hg doesn't directly support a revision whose >> > committer wasn't it's author > >> In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a >> patch by me, the s-o-b's would be: >> >> Signed-off-by: Felipe Contreras >> Signed-off-by: John Bailey > > For the list archive... > > This is NOT how this is handled in git. This is inline metadata (part of > the commit message). It's a Linux convention, not part of git. In other > words, git doesn't require Signed-off-by lines, and I could use > Signed-off-by lines with version control systems other than git. It is part of git: % git commit --signoff -s, --signoff Add Signed-off-by line by the committer at the end of the commit log message. It's used in git.git, and tools recognize it: http://git.kernel.org/?p=git/git.git;a=log >> > To get equivalent behavior out of monotone's git_export command, I'd also have >> > needed to implement a patch. ?It would have been more difficult to patch >> > monotone's C++ code for the git fast-export stuff than it was to patch convert's >> > python code. >> >> No, you could just use 'git filter-branch' as I do in pidgin-git-import. > ... from earlier... >> There is no advantage from hg's convert whatsoever. > > The fact that we avoid using a third version control system in the > middle is arguably an advantage. > > That said, `hg convert`'s (lack of) speed is a disadvantage, albeit > minor since it only needs to be run once. If you'd like to improve the > migration process, I'll certainly accept patches, as you know. You mean, more than the ones I have already contributed? >> ?2) Always provide valid authors. In git, they are in the form "Real Name >> ? ? ", and the mail part is _mandatory_. If there's no mail >> ? ? address, would make sense. > > You're asking us to put fake data into our repository. I don't know why > we'd want to do that. Since git requires it, why not just add it as part > of the hg -> git conversion, if and only if a revision's author doesn't > contain /<.*>/? Fine. Make things more difficult then. -- Felipe Contreras From chris@growl.info Mon Feb 7 23:49:46 2011 From: chris at growl.info (Christopher Forsythe) Date: Mon, 7 Feb 2011 22:49:46 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 2528 Lines: 56 On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras < felipe.contreras at gmail.com> wrote: > On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. > wrote: > > > > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: > > > >> What you are basically saying is: monotone the tool we know, and we > >> are comfortable with > > > > This is a perfectly good reason, by itself, when combined with "and > monotone can do the job we want it to do." Time is our most precious asset. > > Ah, some honesty. That's all I'm saying; if you don't want to do a > careful analysis, fine, just say so. If mercurial turns out not to be > the best choice, don't claim you did a careful analysis, because there > isn't any. > > And yeah, that's a perfectly good reason... for a weekend project. I > still maintain that the last analysis (that resulted in monotone > chosen as the tool) was not done correctly (the main argument was the > big space, and nobody bothered to ask how to reduce it; git-repack), > and back at that time people said that before choosing another tool, a > careful analysis would need to be done, so that the right tool is > picked. I guess talk is cheap. > > Adium did do an analysis like you are suggesting, back in 2009 they switched to mercurial http://trac.adium.im/wiki/DistributedVersionControl I do not believe that the pidgin guys will change their minds at this point. However, I do think that you could aleviate Evan's point here Felipe. You (or someone else) could maintain a very in depth list of pros and cons of all currently popular version systems. I believe the best way to do this would be to remain objective, and be pedantic. If an in depth analysis existed like this now, I believe what you are arguing for would not be an issue. There are new things to bring up, such as the hg-git command to access git repos, and conversion problems that could all be well documented. Plus for extra credit a beginner's guide to each version control system, with examples of how to do each thing and also a separate document explaining differences in the version control system, would really make this decision for *every single oss project out there*. That all said, I vote for mercurial (as if my vote matters). I hate git error messages when I get them (no need to reply to this point, my opinion won't change here). Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecoffey@gmail.com Mon Feb 7 23:56:18 2011 From: ecoffey at gmail.com (Eoin Coffey) Date: Mon, 7 Feb 2011 21:56:18 -0700 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> Message-ID: Status: O Content-Length: 851 Lines: 23 On Mon, Feb 7, 2011 at 8:57 PM, Felipe Contreras wrote: >> Many Pidgin developers have used hg extensively at work, on other open >> source projects, and on their own time. ?We (I am included in that >> group) have considered it very successful at actually *getting things >> done*. ?It is fast, it is accurate, it branches and merges cleanly, it >> runs everywhere, and it is comfortable to use. ?Those are the reasons >> we are choosing it. > > git is also fast, accurate, branches and merges cleanly, it runs > everywhere, and is comfortable to use. > Git runs everywhere, but not as cleanly on windows as on the unixes. I've used both tools, git more than hg, on windows and hg was definitely more comfortable. I think this was a point brought up earlier when someone was mentioning the vulture project. -Eoin From rekkanoryo@rekkanoryo.org Tue Feb 8 00:01:56 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Tue, 08 Feb 2011 00:01:56 -0500 Subject: Migration considerations In-Reply-To: References: Message-ID: <4D50CE44.1000701@rekkanoryo.org> Status: O Content-Length: 4156 Lines: 85 On 02/07/2011 07:33 PM, Felipe Contreras wrote: > I wrote that svn-patch-authors file, and a simple 'git filter-branch' script > fixes the authors in no time: > https://github.com/felipec/pidgin-git-import/blob/fc-svn-fixes/fix-svn-authors I thought I mentioned that it was your partial map. I apologize for not doing so. That said, Richard *did* correctly point that out in the next message in the thread. > There is no advantage from hg's convert whatsoever. Except the avoidance of a middle-man git repo that isn't strictly necessary. I'm willing to trade 30 hours for the simplicity of avoiding yet another tool in the process. It's not like we're active enough that it's going to kill us to have a 48-hour freeze on commits and pushes. > I wrote that file, as you can see in the hg log. We have been collaborating, if > you take a closer look a the pidgin-mtn-conv-files repo you would see that I > have contributed a lot of work. Yes, you've contributed some work. And I thank you for that. I will gladly accept contributions that make our converted history more accurate. > In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a > patch by me, the s-o-b's would be: > > Signed-off-by: Felipe Contreras > Signed-off-by: John Bailey Again, as Richard pointed out, these are not "in" git. They are changelog-inline metadata that the Linux kernel adopted. Yes, they've caught on with other projects. That doesn't make them a gitism. We could use these in hg, bzr, darcs, mtn, and even in cvs, rcs, and SCCS. They have merit, but I'd rather have seen something like: Originated-By: Some Random Idiot Approved-By: John Bailey Approved-By: Someone Else > No, you could just use 'git filter-branch' as I do in pidgin-git-import. That would be perfectly acceptable to me if we were converting to git. But we're not converting to git. I don't want a third tool in the conversion process. > Now, one of the proposals was to provide both git and hg repos, however, it > would be great if you store data that can be easily exported to git. > > 1) Provide both committer and author. Either with Signed-off-by or some other > method, but you have to provide both somehow. > 2) Always provide valid authors. In git, they are in the form "Real Name > ", and the mail part is _mandatory_. If there's no mail > address, would make sense. I agree it would be a nice convenience to provide a git "mirror" of the hg repo. That said, it's not strictly necessary, as there is a way a git user can use an hg repo transparently with git, conveniently called git-hg. At this point I don't care whether someone other than me wants to maintain such an "official" mirror or if our official stance will be to use git-hg. Aside from that, it was always my intention to set policy that all people must identify themselves in the "User Name " format. However, I'm not willing to clutter up our history with "" simply because git requires something between angle brackets in their author and committer fields. Sorry, but our VCS of choice doesn't restrict us in this manner. > Also, remember that the idea was to start a repository from scratch, so, even > if the conversion tool is not finished yet, that doesn't matter as it can > always be fixed later on. It was an idea that was discussed. As I recall, I'm the only one who expressed interest in actually doing any of the creation and subrepo joining and whatnot. Unless someone else wants it also, the idea is dead. That said, I wanted the fresh start to happen at 3.0.0, not immediately, so things can't be left temporarily and fixed later. It has to be perfect at the beginning. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From ecoffey@gmail.com Tue Feb 8 00:04:40 2011 From: ecoffey at gmail.com (Eoin Coffey) Date: Mon, 7 Feb 2011 22:04:40 -0700 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 3040 Lines: 67 On Mon, Feb 7, 2011 at 9:49 PM, Christopher Forsythe wrote: > > > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras > wrote: >> >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. >> wrote: >> > >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: >> > >> >> What you are basically saying is: monotone the tool we know, and we >> >> are comfortable with >> > >> > This is a perfectly good reason, by itself, when combined with "and >> > monotone can do the job we want it to do." ?Time is our most precious asset. >> >> Ah, some honesty. That's all I'm saying; if you don't want to do a >> careful analysis, fine, just say so. If mercurial turns out not to be >> the best choice, don't claim you did a careful analysis, because there >> isn't any. >> >> And yeah, that's a perfectly good reason... for a weekend project. I >> still maintain that the last analysis (that resulted in monotone >> chosen as the tool) was not done correctly (the main argument was the >> big space, and nobody bothered to ask how to reduce it; git-repack), >> and back at that time people said that before choosing another tool, a >> careful analysis would need to be done, so that the right tool is >> picked. I guess talk is cheap. >> > > > Adium did do an analysis like you are suggesting, back in 2009 they switched > to mercurial > http://trac.adium.im/wiki/DistributedVersionControl > I do not believe that the pidgin guys will change their minds at this point. > However, I do think that you could aleviate Evan's point here Felipe. You > (or someone else) could maintain a very in depth list of pros and cons of > all currently popular version systems. I believe the best way to do this > would be to remain objective, and be pedantic. If an in depth analysis > existed like this now, I believe what you are arguing for would not be an > issue. There are new things to bring up, such as the hg-git command to > access git repos, and conversion problems that could all be well documented. > Plus for extra credit a beginner's guide to each version control system, > with examples of how to do each thing and also a separate document > explaining differences in the version control system, would really make this > decision for *every single oss project out there*. > That all said, I vote for mercurial (as if my vote matters). I hate git > error messages when I get them (no need to reply to this point, my opinion > won't change here). > Chris > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel > > Something else entirely to consider is the killer app that is github. More and more open source projects are hosting their official repo there. The UI is quick and efficient, lots of great features (pull requests, git enabled wikis, and issues come to mind). If someone ever gets tired of hosting all the infrastructure, github would do a lot of that work for you :-) From chris@growl.info Tue Feb 8 00:09:05 2011 From: chris at growl.info (Christopher Forsythe) Date: Mon, 7 Feb 2011 23:09:05 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 3678 Lines: 97 On Mon, Feb 7, 2011 at 11:04 PM, Eoin Coffey wrote: > On Mon, Feb 7, 2011 at 9:49 PM, Christopher Forsythe > wrote: > > > > > > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras > > wrote: > >> > >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. > >> wrote: > >> > > >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: > >> > > >> >> What you are basically saying is: monotone the tool we know, and we > >> >> are comfortable with > >> > > >> > This is a perfectly good reason, by itself, when combined with "and > >> > monotone can do the job we want it to do." Time is our most precious > asset. > >> > >> Ah, some honesty. That's all I'm saying; if you don't want to do a > >> careful analysis, fine, just say so. If mercurial turns out not to be > >> the best choice, don't claim you did a careful analysis, because there > >> isn't any. > >> > >> And yeah, that's a perfectly good reason... for a weekend project. I > >> still maintain that the last analysis (that resulted in monotone > >> chosen as the tool) was not done correctly (the main argument was the > >> big space, and nobody bothered to ask how to reduce it; git-repack), > >> and back at that time people said that before choosing another tool, a > >> careful analysis would need to be done, so that the right tool is > >> picked. I guess talk is cheap. > >> > > > > > > Adium did do an analysis like you are suggesting, back in 2009 they > switched > > to mercurial > > http://trac.adium.im/wiki/DistributedVersionControl > > I do not believe that the pidgin guys will change their minds at this > point. > > However, I do think that you could aleviate Evan's point here Felipe. You > > (or someone else) could maintain a very in depth list of pros and cons of > > all currently popular version systems. I believe the best way to do this > > would be to remain objective, and be pedantic. If an in depth analysis > > existed like this now, I believe what you are arguing for would not be an > > issue. There are new things to bring up, such as the hg-git command to > > access git repos, and conversion problems that could all be well > documented. > > Plus for extra credit a beginner's guide to each version control system, > > with examples of how to do each thing and also a separate document > > explaining differences in the version control system, would really make > this > > decision for *every single oss project out there*. > > That all said, I vote for mercurial (as if my vote matters). I hate git > > error messages when I get them (no need to reply to this point, my > opinion > > won't change here). > > Chris > > > > _______________________________________________ > > Devel mailing list > > Devel at pidgin.im > > http://pidgin.im/cgi-bin/mailman/listinfo/devel > > > > > > Something else entirely to consider is the killer app that is github. > More and more open source projects are hosting their official repo > there. The UI is quick and efficient, lots of great features (pull > requests, git enabled wikis, and issues come to mind). If someone > ever gets tired of hosting all the infrastructure, github would do a > lot of that work for you :-) > I'll replace your paragraph with one of my own, using your words with my regular expression changes. It's computer magic! ;) s/git/mercurial/ s/github/google code hosting/ Alternatively: s/git/mercurial/ s/github/bitbucket/ You can go on and on :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecoffey@gmail.com Tue Feb 8 00:12:28 2011 From: ecoffey at gmail.com (Eoin Coffey) Date: Mon, 7 Feb 2011 22:12:28 -0700 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 3886 Lines: 103 On Mon, Feb 7, 2011 at 10:09 PM, Christopher Forsythe wrote: > > > On Mon, Feb 7, 2011 at 11:04 PM, Eoin Coffey wrote: >> >> On Mon, Feb 7, 2011 at 9:49 PM, Christopher Forsythe >> wrote: >> > >> > >> > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras >> > wrote: >> >> >> >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. >> >> wrote: >> >> > >> >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: >> >> > >> >> >> What you are basically saying is: monotone the tool we know, and we >> >> >> are comfortable with >> >> > >> >> > This is a perfectly good reason, by itself, when combined with "and >> >> > monotone can do the job we want it to do." ?Time is our most precious >> >> > asset. >> >> >> >> Ah, some honesty. That's all I'm saying; if you don't want to do a >> >> careful analysis, fine, just say so. If mercurial turns out not to be >> >> the best choice, don't claim you did a careful analysis, because there >> >> isn't any. >> >> >> >> And yeah, that's a perfectly good reason... for a weekend project. I >> >> still maintain that the last analysis (that resulted in monotone >> >> chosen as the tool) was not done correctly (the main argument was the >> >> big space, and nobody bothered to ask how to reduce it; git-repack), >> >> and back at that time people said that before choosing another tool, a >> >> careful analysis would need to be done, so that the right tool is >> >> picked. I guess talk is cheap. >> >> >> > >> > >> > Adium did do an analysis like you are suggesting, back in 2009 they >> > switched >> > to mercurial >> > http://trac.adium.im/wiki/DistributedVersionControl >> > I do not believe that the pidgin guys will change their minds at this >> > point. >> > However, I do think that you could aleviate Evan's point here Felipe. >> > You >> > (or someone else) could maintain a very in depth list of pros and cons >> > of >> > all currently popular version systems. I believe the best way to do this >> > would be to remain objective, and be pedantic. If an in depth analysis >> > existed like this now, I believe what you are arguing for would not be >> > an >> > issue. There are new things to bring up, such as the hg-git command to >> > access git repos, and conversion problems that could all be well >> > documented. >> > Plus for extra credit a beginner's guide to each version control system, >> > with examples of how to do each thing and also a separate document >> > explaining differences in the version control system, would really make >> > this >> > decision for *every single oss project out there*. >> > That all said, I vote for mercurial (as if my vote matters). I hate git >> > error messages when I get them (no need to reply to this point, my >> > opinion >> > won't change here). >> > Chris >> > >> > _______________________________________________ >> > Devel mailing list >> > Devel at pidgin.im >> > http://pidgin.im/cgi-bin/mailman/listinfo/devel >> > >> > >> >> Something else entirely to consider is the killer app that is github. >> More and more open source projects are hosting their official repo >> there. ?The UI is quick and efficient, lots of great features (pull >> requests, git enabled wikis, and issues come to mind). ?If someone >> ever gets tired of hosting all the infrastructure, github would do a >> lot of that work for you :-) > > > > I'll replace your paragraph with one of my own, using your words with my > regular expression changes. It's computer magic! ;) > > > s/git/mercurial/ > s/github/google code hosting/ > Alternatively: > s/git/mercurial/ > s/github/bitbucket/ > > > You can go on and on :) > > Heh, I see what you're saying, but GitHub has been the most enjoyable code hosting solution for me; granted I haven't used bitbucket that extensively. From felipe.contreras@gmail.com Tue Feb 8 00:15:16 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 07:15:16 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 2639 Lines: 65 On Tue, Feb 8, 2011 at 6:49 AM, Christopher Forsythe wrote: > > > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras > wrote: >> >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. >> wrote: >> > >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: >> > >> >> What you are basically saying is: monotone the tool we know, and we >> >> are comfortable with >> > >> > This is a perfectly good reason, by itself, when combined with "and >> > monotone can do the job we want it to do." ?Time is our most precious asset. >> >> Ah, some honesty. That's all I'm saying; if you don't want to do a >> careful analysis, fine, just say so. If mercurial turns out not to be >> the best choice, don't claim you did a careful analysis, because there >> isn't any. >> >> And yeah, that's a perfectly good reason... for a weekend project. I >> still maintain that the last analysis (that resulted in monotone >> chosen as the tool) was not done correctly (the main argument was the >> big space, and nobody bothered to ask how to reduce it; git-repack), >> and back at that time people said that before choosing another tool, a >> careful analysis would need to be done, so that the right tool is >> picked. I guess talk is cheap. >> > > > Adium did do an analysis like you are suggesting, back in 2009 they switched > to mercurial > http://trac.adium.im/wiki/DistributedVersionControl Yes, that's what I'm talking about, but if you see closely, there's no disadvantage of using git. The only one listed is that revision numbers are unfriendly, but the "friendly" ones of mercurial are bogus (only local), plus you hardly ever need to use them. > I do not believe that the pidgin guys will change their minds at this point. > However, I do think that you could aleviate Evan's point here Felipe. You > (or someone else) could maintain a very in depth list of pros and cons of > all currently popular version systems. I believe the best way to do this > would be to remain objective, and be pedantic. If an in depth analysis > existed like this now, I believe what you are arguing for would not be an > issue. You mean like this? http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ The link to the detailed comparison is there. > That all said, I vote for mercurial (as if my vote matters). I hate git > error messages when I get them (no need to reply to this point, my opinion > won't change here). Of course not, you would need to use branches and remote repos to see what you are missing. See my blog post. -- Felipe Contreras From kstange@pidgin.im Tue Feb 8 00:16:19 2011 From: kstange at pidgin.im (Kevin Stange) Date: Mon, 07 Feb 2011 23:16:19 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: <4D50D1A3.9040903@pidgin.im> Status: O Content-Length: 425 Lines: 16 On 02/07/2011 11:09 PM, Christopher Forsythe wrote: > s/git/mercurial/ > s/github/google code hosting/ You should really reverse the order of these. :P Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From chris@growl.info Tue Feb 8 00:39:41 2011 From: chris at growl.info (Christopher Forsythe) Date: Mon, 7 Feb 2011 23:39:41 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 3244 Lines: 88 On Mon, Feb 7, 2011 at 11:15 PM, Felipe Contreras < felipe.contreras at gmail.com> wrote: > On Tue, Feb 8, 2011 at 6:49 AM, Christopher Forsythe > wrote: > > > > > > On Mon, Feb 7, 2011 at 10:24 PM, Felipe Contreras > > wrote: > >> > >> On Tue, Feb 8, 2011 at 6:05 AM, Evan Schoenberg, M.D. > >> wrote: > >> > > >> > On Feb 7, 2011, at 9:57 PM, Felipe Contreras wrote: > >> > > >> >> What you are basically saying is: monotone the tool we know, and we > >> >> are comfortable with > >> > > >> > This is a perfectly good reason, by itself, when combined with "and > >> > monotone can do the job we want it to do." Time is our most precious > asset. > >> > >> Ah, some honesty. That's all I'm saying; if you don't want to do a > >> careful analysis, fine, just say so. If mercurial turns out not to be > >> the best choice, don't claim you did a careful analysis, because there > >> isn't any. > >> > >> And yeah, that's a perfectly good reason... for a weekend project. I > >> still maintain that the last analysis (that resulted in monotone > >> chosen as the tool) was not done correctly (the main argument was the > >> big space, and nobody bothered to ask how to reduce it; git-repack), > >> and back at that time people said that before choosing another tool, a > >> careful analysis would need to be done, so that the right tool is > >> picked. I guess talk is cheap. > >> > > > > > > Adium did do an analysis like you are suggesting, back in 2009 they > switched > > to mercurial > > http://trac.adium.im/wiki/DistributedVersionControl > > Yes, that's what I'm talking about, but if you see closely, there's no > disadvantage of using git. The only one listed is that revision > numbers are unfriendly, but the "friendly" ones of mercurial are bogus > (only local), plus you hardly ever need to use them. > > > I do not believe that the pidgin guys will change their minds at this > point. > > However, I do think that you could aleviate Evan's point here Felipe. You > > (or someone else) could maintain a very in depth list of pros and cons of > > all currently popular version systems. I believe the best way to do this > > would be to remain objective, and be pedantic. If an in depth analysis > > existed like this now, I believe what you are arguing for would not be an > > issue. > > You mean like this? > > http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ > > No, there's no simple table like in the adium wiki page. I mean that specifically, with discussion below perhaps. > The link to the detailed comparison is there. > > > That all said, I vote for mercurial (as if my vote matters). I hate git > > error messages when I get them (no need to reply to this point, my > opinion > > won't change here). > > Of course not, you would need to use branches and remote repos to see > what you are missing. See my blog post. > > I do have git for work, and I use branches and remote repos. I still don't like the error messages. > -- > Felipe Contreras > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zacwest@gmail.com Tue Feb 8 07:34:05 2011 From: zacwest at gmail.com (Zachary West) Date: Tue, 8 Feb 2011 07:34:05 -0500 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 1731 Lines: 44 On Mon, Feb 7, 2011 at 23:49, Christopher Forsythe wrote: > > Adium did do an analysis like you are suggesting, back in 2009 they switched to mercurial > http://trac.adium.im/wiki/DistributedVersionControl Since I'm the one that did the Adium conversion, SVN -> Mercurial was fantastic. It is infinitely better than SVN. Is it better than git? I don't know. I do not regret going with Mercurial over Git, but I am not sure I'd make the same decision to go with Mercurial at this point. > s/git/mercurial/ > s/github/google code hosting/ > > Alternatively: > > s/git/mercurial/ > s/github/bitbucket/ To compare Github and Bitbucket in that respect is unfortunately not so great. Bitbucket has a significantly smaller user base, and Git has really overtaken Mercurial significantly in the past year or two. From my perspective, I _never_ see a project use Mercurial, but I _always_ see a project use Git. Ad populum choices aren't always the right ones, for sure, but it might be worth the hard look to see whether or not Git's popularity is a more convincing reason to go with it over Mercurial, all other things being equal. Github is pretty fantastic, and considering how difficult submitting patches is to code-bases as large as Adium's or Pidgin's, it might even be a more preferred way of getting changes into the proper repository. That being said, I don't think it makes much of a difference which you go with. The end goal is fine with both of them: you have a faster, easier-to-use DVCS that likely will promote more people grabbing it. I just hope Mercurial doesn't end up being like Monotone in a few years and this conversation has to start all over again, for all of us. -- Zachary West From felipe.contreras@gmail.com Tue Feb 8 07:37:38 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 14:37:38 +0200 Subject: Migration considerations In-Reply-To: <4D50CE44.1000701@rekkanoryo.org> References: <4D50CE44.1000701@rekkanoryo.org> Message-ID: Status: O Content-Length: 5279 Lines: 117 On Tue, Feb 8, 2011 at 7:01 AM, John Bailey wrote: > On 02/07/2011 07:33 PM, Felipe Contreras wrote: >> I wrote that svn-patch-authors file, and a simple 'git filter-branch' script >> fixes the authors in no time: >> https://github.com/felipec/pidgin-git-import/blob/fc-svn-fixes/fix-svn-authors > > I thought I mentioned that it was your partial map. ?I apologize for not doing > so. ?That said, Richard *did* correctly point that out in the next message in > the thread. Good. I was wondering why you didn't notice. >> There is no advantage from hg's convert whatsoever. > > Except the avoidance of a middle-man git repo that isn't strictly necessary. > I'm willing to trade 30 hours for the simplicity of avoiding yet another tool in > the process. ?It's not like we're active enough that it's going to kill us to > have a 48-hour freeze on commits and pushes. The problem is that the conversion scripts are a work in progress, 64 commits so far. And most of time they are changed you have to rebuild the repo. I'm aware of that pain, that's why I even profiled 'mtn git_export' and fixed the bigger bottlenecks, and now it takes about 20min to do the full conversion. >> I wrote that file, as you can see in the hg log. We have been collaborating, if >> you take a closer look a the pidgin-mtn-conv-files repo you would see that I >> have contributed a lot of work. > > Yes, you've contributed some work. ?And I thank you for that. ?I will gladly > accept contributions that make our converted history more accurate. > >> In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a >> patch by me, the s-o-b's would be: >> >> Signed-off-by: Felipe Contreras >> Signed-off-by: John Bailey > > Again, as Richard pointed out, these are not "in" git. ?They are > changelog-inline metadata that the Linux kernel adopted. ?Yes, they've caught on > with other projects. ?That doesn't make them a gitism. ?We could use these in > hg, bzr, darcs, mtn, and even in cvs, rcs, and SCCS. ?They have merit, but I'd > rather have seen something like: See git commit --signoff: http://www.kernel.org/pub/software/scm/git/docs/git-commit.html And git format-patch --signoff: http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html And git send-email --[no-]signed-off-by-cc --suppress-cc=cc,sob http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html It's very much part of git. > Originated-By: Some Random Idiot > Approved-By: John Bailey > Approved-By: Someone Else Sure, you can add those, but in git only Signed-off-by and Cc have special meaning. >> No, you could just use 'git filter-branch' as I do in pidgin-git-import. > > That would be perfectly acceptable to me if we were converting to git. ?But > we're not converting to git. ?I don't want a third tool in the conversion process. You are quite fond of providing non-arguments. You say you don't want a third tool in the conversion process, but you don't have any valid reason. >> Now, one of the proposals was to provide both git and hg repos, however, it >> would be great if you store data that can be easily exported to git. >> >> ?1) Provide both committer and author. Either with Signed-off-by or some other >> ? ? method, but you have to provide both somehow. >> ?2) Always provide valid authors. In git, they are in the form "Real Name >> ? ? ", and the mail part is _mandatory_. If there's no mail >> ? ? address, would make sense. > > I agree it would be a nice convenience to provide a git "mirror" of the hg repo. > ?That said, it's not strictly necessary, as there is a way a git user can use an > hg repo transparently with git, conveniently called git-hg. ?At this point I > don't care whether someone other than me wants to maintain such an "official" > mirror or if our official stance will be to use git-hg. Awful. You don't want to use a "third tool" in the conversion process, which happens rarely, but you want to force that to contributors that prefer git. Very empathetic of you. >> Also, remember that the idea was to start a repository from scratch, so, even >> if the conversion tool is not finished yet, that doesn't matter as it can >> always be fixed later on. > > It was an idea that was discussed. ?As I recall, I'm the only one who expressed > interest in actually doing any of the creation and subrepo joining and whatnot. > ?Unless someone else wants it also, the idea is dead. ?That said, I wanted the > fresh start to happen at 3.0.0, not immediately, so things can't be left > temporarily and fixed later. ?It has to be perfect at the beginning. Awful. So the idea of having a repository for each project is dead too. And no conversion is ever perfect. You *will* have issues that are found after you migrate, and they would have to stay forever in the history. Or at least until you realize that hg was not a good choice. I for starters can think of a list of mtn commits that, like svn commits, didn't have the right patch author, this guideline was introduced only later, when I pointed that out. Cheers. -- Felipe Contreras From chris@growl.info Tue Feb 8 09:52:37 2011 From: chris at growl.info (Chris Forsythe) Date: Tue, 8 Feb 2011 08:52:37 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 2154 Lines: 57 On Feb 8, 2011, at 6:34 AM, Zachary West wrote: > On Mon, Feb 7, 2011 at 23:49, Christopher Forsythe wrote: >> >> Adium did do an analysis like you are suggesting, back in 2009 they switched to mercurial >> http://trac.adium.im/wiki/DistributedVersionControl > > Since I'm the one that did the Adium conversion, SVN -> Mercurial was > fantastic. It is infinitely better than SVN. > > Is it better than git? I don't know. I do not regret going with > Mercurial over Git, but I am not sure I'd make the same decision to go > with Mercurial at this point. > >> s/git/mercurial/ >> s/github/google code hosting/ >> >> Alternatively: >> >> s/git/mercurial/ >> s/github/bitbucket/ > > To compare Github and Bitbucket in that respect is unfortunately not > so great. Bitbucket has a significantly smaller user base, The only point I was making here is that generally you can interchange these things. Overall they are all pretty similar. > and Git has > really overtaken Mercurial significantly in the past year or two. From > my perspective, I _never_ see a project use Mercurial, but I _always_ > see a project use Git. > > Ad populum choices aren't always the right ones, for sure, but it > might be worth the hard look to see whether or not Git's popularity is > a more convincing reason to go with it over Mercurial, all other > things being equal. Github is pretty fantastic, and considering how > difficult submitting patches is to code-bases as large as Adium's or > Pidgin's, it might even be a more preferred way of getting changes > into the proper repository. > > That being said, I don't think it makes much of a difference which you > go with. The end goal is fine with both of them: you have a faster, > easier-to-use DVCS that likely will promote more people grabbing it. I > just hope Mercurial doesn't end up being like Monotone in a few years > and this conversation has to start all over again, for all of us. > > -- > Zachary West > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel From rlaager@wiktel.com Tue Feb 8 10:54:27 2011 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 08 Feb 2011 09:54:27 -0600 Subject: Migration considerations In-Reply-To: References: <1297130994.3795.21.camel@watermelon.coderich.net> Message-ID: <1297180467.3795.55.camel@watermelon.coderich.net> Status: O Content-Length: 1412 Lines: 38 On Tue, 2011-02-08 at 06:42 +0200, Felipe Contreras wrote: > > This is inline metadata (part of > > the commit message). It's a Linux convention, not part of git. > > It is part of git: > % git commit --signoff I forgot git had that command line syntactic sugar. The underlying point, however, was that git has *first-class* author and commit fields. Signoffs are related (and good). > >> No, you could just use 'git filter-branch' as I do in pidgin-git-import. ... > > That said, `hg convert`'s (lack of) speed is a disadvantage, albeit > > minor since it only needs to be run once. If you'd like to improve the > > migration process, I'll certainly accept patches, as you know. > > You mean, more than the ones I have already contributed? I don't see any filter-branch code in your fc-updates branch: rlaager at HOSTNAME:~/src/pidgin-hg-convert$ git log | head -n1 commit 00b37886a84809ed86e08737eab87379c32fab04 rlaager at HOSTNAME:~/src/pidgin-hg-convert$ grep filter * rlaager at HOSTNAME:~/src/pidgin-hg-convert$ migrate.sh in your branch still calls hg convert. I must be missing the patch you're referring to. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From felipe.contreras@gmail.com Tue Feb 8 12:09:35 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Tue, 8 Feb 2011 19:09:35 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: Status: O Content-Length: 1514 Lines: 33 On Tue, Feb 8, 2011 at 2:34 PM, Zachary West wrote: > Ad populum choices aren't always the right ones, for sure, but it > might be worth the hard look to see whether or not Git's popularity is > a more convincing reason to go with it over Mercurial, all other > things being equal. Indeed. The interesting question would be: why is git more popular than mercurial? I know pretty well why. I would have expected an analysis document stating why despite that fact, Pidgin developers have chosen hg over it. So far, I haven't heard any compelling reason. > That being said, I don't think it makes much of a difference which you > go with. The end goal is fine with both of them: you have a faster, > easier-to-use DVCS that likely will promote more people grabbing it. I > just hope Mercurial doesn't end up being like Monotone in a few years > and this conversation has to start all over again, for all of us. To be fair, I think mercurial is a fantastic choice compared to monotone (and over SVN), and I doubt it would turn out to be another monotone. However, I feel confident that year after year git would become more and more popular, and mercurial user-base would have to decrease as a result, not because mercurial is bad, but because git is so much better than anything else. A few years from now I think it would be obvious that git would have been a better choice, but how much would this choice hurt is impossible to say, probably not that much. Cheers. -- Felipe Contreras From morshed.nader@gmail.com Tue Feb 8 15:24:32 2011 From: morshed.nader at gmail.com (Nader Morshed) Date: Tue, 8 Feb 2011 12:24:32 -0800 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> Message-ID: <20110208122432.64c7ffb7.morshed.nader@gmail.com> Status: O Content-Length: 2269 Lines: 49 > To be fair, I think mercurial is a fantastic choice compared to > monotone (and over SVN), and I doubt it would turn out to be another > monotone. However, I feel confident that year after year git would > become more and more popular, and mercurial user-base would have to > decrease as a result, not because mercurial is bad, but because git is > so much better than anything else. A few years from now I think it > would be obvious that git would have been a better choice, but how > much would this choice hurt is impossible to say, probably not that > much. I said something in the original thread with regards to git on windows that I think might be worth clarifying: It is really, really poorly maintained. Just last month, I had to delete and re-download the entire gtk+ repository because of an issue with pulling updates. The msysgit port states on its own front page: > Please note that there are not enough contributors to the msysGit > project to offer commercial-grade support; if you do not have the > means to fix your problems (possibly with valuable advice from the > msysGit mailing list), or to entice people who can fix them, it is > unlikely that your problem gets solved. http://code.google.com/p/msysgit/ And additionally they closed down their issue tracker with the message: > The msysGit issue tracker has been disabled because the process does > not work. If you are interested in getting an issue resolved (and you > are willing to put in the effort it takes to see to it until it is > fixed), please feel free to mail to the msysGit mailing list. > > Note: if you are not willing to put in an effort to get the problem > solved, you should expect other people to be as enthusiastic about > fixing it. http://code.google.com/p/msysgit/wiki/IssueTracker?tm=3 Keep in mind that Pidgin lists Windows as a supported platform, having the code base accessible and functional on Windows is a great help to patch writers like myself who use it as their main platform. Brushing aside support for effectively means cutting out those contributors and making it another roadblock for people wanting to build from source, as if there weren't enough for building code on the platform already... -- Nader Morshed From felipe.contreras@gmail.com Tue Feb 8 18:12:44 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Feb 2011 01:12:44 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: <20110208122432.64c7ffb7.morshed.nader@gmail.com> References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> <20110208122432.64c7ffb7.morshed.nader@gmail.com> Message-ID: Status: O Content-Length: 2991 Lines: 67 On Tue, Feb 8, 2011 at 10:24 PM, Nader Morshed wrote: >> To be fair, I think mercurial is a fantastic choice compared to >> monotone (and over SVN), and I doubt it would turn out to be another >> monotone. However, I feel confident that year after year git would >> become more and more popular, and mercurial user-base would have to >> decrease as a result, not because mercurial is bad, but because git is >> so much better than anything else. A few years from now I think it >> would be obvious that git would have been a better choice, but how >> much would this choice hurt is impossible to say, probably not that >> much. > > I said something in the original thread with regards to git on windows > that I think might be worth clarifying: It is really, really poorly > maintained. Just last month, I had to delete and re-download the entire > gtk+ repository because of an issue with pulling updates. Did you report the issue? How do we know it was not a user problem? > The msysgit port states on its own front page: > >> Please note that there are not enough contributors to the msysGit >> project to offer commercial-grade support; if you do not have the >> means to fix your problems (possibly with valuable advice from the >> msysGit mailing list), or to entice people who can fix them, it is >> unlikely that your problem gets solved. > > http://code.google.com/p/msysgit/ Isn't that the same on most projects? > And additionally they closed down their issue tracker with the message: > >> The msysGit issue tracker has been disabled because the process does >> not work. If you are interested in getting an issue resolved (and you >> are willing to put in the effort it takes to see to it until it is >> fixed), please feel free to mail to the msysGit mailing list. >> >> Note: if you are not willing to put in an effort to get the problem >> solved, you should expect other people to be as enthusiastic about >> fixing it. > > http://code.google.com/p/msysgit/wiki/IssueTracker?tm=3 So? The Git project doesn't have a bugzilla at all (they say it's not needed, and wouldn't work), that doesn't mean anything. > Keep in mind that Pidgin lists Windows as a supported platform, having > the code base accessible and functional on Windows is a great help to > patch writers like myself who use it as their main platform. Brushing > aside support for effectively means cutting out those contributors and > making it another roadblock for people wanting to build from source, as > if there weren't enough for building code on the platform already... Well, 35% of git users are on Windows according to the last survey[1], and there isn't a huge cry over bad Windows support as it used to be some years ago. So, I'd say for the most part it works fine. Anyway, even if git was chosen, there would be hg clones, and you could use that if you really wanted to. Cheers. [1] https://git.wiki.kernel.org/index.php/GitSurvey2010 -- Felipe Contreras From felipe.contreras@gmail.com Tue Feb 8 18:54:08 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Feb 2011 01:54:08 +0200 Subject: Migration considerations In-Reply-To: <1297180467.3795.55.camel@watermelon.coderich.net> References: <1297130994.3795.21.camel@watermelon.coderich.net> <1297180467.3795.55.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 2209 Lines: 60 On Tue, Feb 8, 2011 at 5:54 PM, Richard Laager wrote: > On Tue, 2011-02-08 at 06:42 +0200, Felipe Contreras wrote: >> > This is inline metadata (part of >> > the commit message). It's a Linux convention, not part of git. >> >> It is part of git: >> % git commit --signoff > > I forgot git had that command line syntactic sugar. The underlying > point, however, was that git has *first-class* author and commit fields. > Signoffs are related (and good). Sure, but they are often not enough: Acked-by: Eric Wong Signed-off-by: Jonathan Nieder Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano Reported-by: Michel Briand Signed-off-by: Nguy?n Th?i Ng?c Duy Signed-off-by: Junio C Hamano But sure, committer and author are part of the database. It's nice to be able to do queries like 'git log --author', or 'git log --committer'. >> >> No, you could just use 'git filter-branch' as I do in pidgin-git-import. > ... >> > That said, `hg convert`'s (lack of) speed is a disadvantage, albeit >> > minor since it only needs to be run once. If you'd like to improve the >> > migration process, I'll certainly accept patches, as you know. >> >> You mean, more than the ones I have already contributed? > > I don't see any filter-branch code in your fc-updates branch: > > rlaager at HOSTNAME:~/src/pidgin-hg-convert$ git log | head -n1 > commit 00b37886a84809ed86e08737eab87379c32fab04 > rlaager at HOSTNAME:~/src/pidgin-hg-convert$ grep filter * > rlaager at HOSTNAME:~/src/pidgin-hg-convert$ > > migrate.sh in your branch still calls hg convert. I must be missing the > patch you're referring to. You said "improve the migration process", not the speed. Anyway, the good stuff is in the usual place: https://github.com/felipec/pidgin-git-import I have added a script that does the repository fixes in a single 'git filter-branch' command. The fixing process takes 30m, which makes the total 50m. I'm sure the git->hg conversion cannot take much more. Cheers. -- Felipe Contreras From queueram@gmail.com Tue Feb 8 23:05:39 2011 From: queueram at gmail.com (Marq Schneider) Date: Tue, 8 Feb 2011 22:05:39 -0600 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> <20110208122432.64c7ffb7.morshed.nader@gmail.com> Message-ID: Status: O Content-Length: 359 Lines: 10 On Tue, Feb 8, 2011 at 17:12, Felipe Contreras wrote: > Well, 35% of git users are on Windows according to the last survey[1] Following your methods on math and statistics, 177% of the people who responded to this survey are using Linux, OSX, Windows, or other OS. > [1] https://git.wiki.kernel.org/index.php/GitSurvey2010 From felipe.contreras@gmail.com Wed Feb 9 04:23:26 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Wed, 9 Feb 2011 11:23:26 +0200 Subject: Moving to Hg without any analysis at all In-Reply-To: References: <20110208005152.GA7745@colt> <0492A25E-9CAF-4864-A483-233D95F691D0@dreskin.net> <20110208122432.64c7ffb7.morshed.nader@gmail.com> Message-ID: Status: O Content-Length: 472 Lines: 14 On Wed, Feb 9, 2011 at 6:05 AM, Marq Schneider wrote: > On Tue, Feb 8, 2011 at 17:12, Felipe Contreras > wrote: >> Well, 35% of git users are on Windows according to the last survey[1] > > Following your methods on math and statistics, 177% of the people who > responded to this survey are using Linux, OSX, Windows, or other OS. This must be a joke... You can use both Windows and Linux =O -- Felipe Contreras From rekkanoryo@rekkanoryo.org Sat Jan 15 13:32:09 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Sat, 15 Jan 2011 13:32:09 -0500 Subject: Time to Leave Monotone Behind? Message-ID: <20110115183209.GC6934@rekkanoryo.org> Status: O Content-Length: 6293 Lines: 117 Hi, all, For almost four years now, we've been using Monotone as our source repository. Over that time, it's proven itself to work very well for us, I think. However, there have always been some annoyances with it. Notable complaints we've had are the time it takes to pull our history into a fresh database and the lack of compatibility with tools. For the pull issue, we hacked around this by using a cron job to generate a bootstrap database and make it available for download, as this was generally faster than a full netsync of our entire history. Tools, on the other hand, have been hit and miss. I remember Mark having trouble with meld after a new monotone release changed some of the 'automate' functionality, breaking meld's use of it. Other useful tools, like monotone-viz, seem to take forever to be updated for even the tiniest change in monotone. Trac ingetration, in particular, has been a problem. While a trac plugin did exist for Monotone, that plugin routinely fell flat on its face, requiring some black magic to fix it. After some time fighting that, we moved to viewmtn. That has been a source of some frustrations as well. We've seen that viewmtn can be very slow, and we've resorted to customizing it to improve some deficiencies we saw. We also resorted to writing our own trac plugin to link revision numbers in trac wiki formatting to the revisions in viewmtn to make up for the lack of a usable trac-monotone integration plugin. Additionally, some of the more useful things that have been desired over time, such as buildbot, are challenging to implement, to say the least. It's been discussed a number of times over the last couple years that we should consider moving away from Monotone. At this point, I'm now inclined to agree. To that end, I propose that we move from Monotone to Mercurial. I'll come back to this in a bit. As many of you who are in the XMPP MUC know, I've been working recently on getting a good conversion from our Monotone database to an hg repository. I've done this a number of times before and consistently failed, but thanks to Augie Fackler (used to be fairly heavily involved in Adium), I now know exactly what the problem was and have been able to work around it quite effectively. Once I was past that point, the next step was to map all our 259 unique authors, many of whom are really the same core group of developers, into sane, consistently formatted author ID's. I then proceeded into branch name mapping. In mapping branch names, mostly I just stripped the beginning 'im.pidgin' off our branch names, but there were a couple other minor tweaks, like making im.pidgin.pidgin become "default", to be consistent with more "normal" hg repositories. In fairness, I must credit Felipe Contreras for about 60-65% of the authormap. His prior work to convert our Monotone repo to git saved me a crapload of time in mapping all the author ID's. I took his author map, made some adjustments, and then filled in the holes when I first worked on the mapping last year. This time, I just filled in the extra authors the gaps (his map was 75-100 authors short of our current state). The branch mapping, however, was all my doing, thanks to the use of 'mtn ls branches --ignore-suspend-certs' and some creative text manipulation. Both of these maps would be useful for migrating to a DVCS other than Mercurial, of course, with some minor adjustments. As for my specific desire to use Mercurial, here are a few things we gain (git may offer some or all of these as well, but I'm not particularly fond of git, as we all know): * Significantly faster initial pulls (10 minutes vs 45 minutes for me) * Significant improvements in speed for essentially all operations * Trac integration via trac-mercurial plugin if we keep the one repository model. * Use of hgweb if we use a multi-repository model, with trac "integration" through similar means to what Adium has done * Ability to use "subrepos"--that is, we could do some creative things like split translations into a separate repository that translators have write access to but have that repository pulled into our source tree for us with the use of the appropriate hg extensions. * Ability to use stock buildbot for build testing of pushed revisions (although if we want to use buildbot on something other than the current im.pidgin.pidgin we need a multi-repo model, as buildbot doesn't handle hg branches that well). * Ability for potential contributors to clone the repository and host it somewhere like bitbucket to make incremental improvements that we can later review and incorporate upstream if we wish (the point here is that a workflow like this is easier in Mercurial than it is in Monotone). * The Adium guys can "fork" our repo and include it in their tree as a subrepo if they want. The current Monotone process is painful for them, and using git would be only slightly less painful due to the increased speed. * We can add additional features to Mercurial as extensions if we need or want to. This is relatively trivial since it's all python. * SSH-based authentication without needing to give every user their own shell account using the mercurial-server package. Using this package we can control write permissions to specific repositories in a multi-repo model, and we can control who is allowed to create repositories on the server. This is all done using SSH public keys, obviously. What do you guys say? For reference, here are some items to consider: * Author and branch maps, migration script, etc: http://hg.guifications.org/pidgin-mtn-conv-files/ * First pass conversion (crude conversion with incomplete mappings): http://hg.guifications.org/pidgin-firstpass/ * First pass repo above with completed mappings (I just ran hg convert on the firstpass repo with maps in place): http://hg.guifications.org/pidgin-firstpass-completedmaps/ John -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From lschiere@pidgin.im Sat Jan 15 16:22:28 2011 From: lschiere at pidgin.im (Luke Schierer) Date: Sat, 15 Jan 2011 16:22:28 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115183209.GC6934@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: Status: O Content-Length: 3311 Lines: 69 On Jan 15, 2011, at 13:32 EST, John Bailey wrote: > Hi, all, > > For almost four years now, we've been using Monotone as our source > repository. Over that time, it's proven itself to work very well for > us, I think. However, there have always been some annoyances with it. > > As for my specific desire to use Mercurial, here are a few things we > gain (git may offer some or all of these as well, but I'm not > particularly fond of git, as we all know): > * Significantly faster initial pulls (10 minutes vs 45 minutes for me) > * Significant improvements in speed for essentially all operations > * Trac integration via trac-mercurial plugin if we keep the one > repository model. > * Use of hgweb if we use a multi-repository model, with trac > "integration" through similar means to what Adium has done > * Ability to use "subrepos"--that is, we could do some creative things > like split translations into a separate repository that translators > have write access to but have that repository pulled into our source > tree for us with the use of the appropriate hg extensions. > * Ability to use stock buildbot for build testing of pushed revisions > (although if we want to use buildbot on something other than the > current im.pidgin.pidgin we need a multi-repo model, as buildbot > doesn't handle hg branches that well). > * Ability for potential contributors to clone the repository and host > it somewhere like bitbucket to make incremental improvements that we > can later review and incorporate upstream if we wish (the point here > is that a workflow like this is easier in Mercurial than it is in > Monotone). > * The Adium guys can "fork" our repo and include it in their tree as a > subrepo if they want. The current Monotone process is painful for > them, and using git would be only slightly less painful due to the > increased speed. > * We can add additional features to Mercurial as extensions if we need > or want to. This is relatively trivial since it's all python. > * SSH-based authentication without needing to give every user their > own shell account using the mercurial-server package. Using this > package we can control write permissions to specific repositories in > a multi-repo model, and we can control who is allowed to create > repositories on the server. This is all done using SSH public keys, > obviously. > Most if not all of these advantages are available with git. I know that John doesn't like git, and his opinion holds more weight than mine a this point, but for what its worth, I prefer git to mercurial. Luke > What do you guys say? > > For reference, here are some items to consider: > * Author and branch maps, migration script, etc: > http://hg.guifications.org/pidgin-mtn-conv-files/ > * First pass conversion (crude conversion with incomplete mappings): > http://hg.guifications.org/pidgin-firstpass/ > * First pass repo above with completed mappings (I just ran hg convert > on the firstpass repo with maps in place): > http://hg.guifications.org/pidgin-firstpass-completedmaps/ > > John > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel From florian@instantbird.org Sat Jan 15 16:36:27 2011 From: florian at instantbird.org (=?ISO-8859-1?Q?Florian_Qu=E8ze?=) Date: Sat, 15 Jan 2011 22:36:27 +0100 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115183209.GC6934@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: Status: O Content-Length: 306 Lines: 12 11 at 19:32, John Bailey wrote: [...] > What do you guys say? >From my Instantbird developer point of view, it would be great if you go ahead and switch to Mercurial. We already use Mercurial for our own source code and to pull the Mozilla source code. -- Florian Qu?ze From morshed.nader@gmail.com Sat Jan 15 17:11:36 2011 From: morshed.nader at gmail.com (Nader Morshed) Date: Sat, 15 Jan 2011 14:11:36 -0800 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: <20110115141136.4f32b6d3.morshed.nader@gmail.com> Status: O Content-Length: 969 Lines: 32 For what it's worth, I would also put my support behind Mercurial. Git on Windows, while getting better, has a bit of a segmented development effort between its Cygwin and MSYS ports. It also doesn't really compare to Mercurial, which I personally feel is packaged and managed a lot better. Mercurial also comes with a stable and well supported GUI, TortoiseHg. On Sat, 15 Jan 2011 22:36:27 +0100 Florian Qu?ze wrote: > 11 at 19:32, John Bailey wrote: > [...] > > What do you guys say? > > >From my Instantbird developer point of view, it would be great if you > go ahead and switch to Mercurial. We already use Mercurial for our own > source code and to pull the Mozilla source code. > > -- > Florian Qu?ze > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel -- Nader Morshed From eion@robbmob.com Sat Jan 15 20:37:38 2011 From: eion at robbmob.com (Eion Robb) Date: Sun, 16 Jan 2011 14:37:38 +1300 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115141136.4f32b6d3.morshed.nader@gmail.com> References: <20110115183209.GC6934@rekkanoryo.org> <20110115141136.4f32b6d3.morshed.nader@gmail.com> Message-ID: Status: O Content-Length: 598 Lines: 14 On 16 January 2011 11:11, Nader Morshed wrote: > For what it's worth, I would also put my support behind Mercurial. Git > on Windows, while getting better, has a bit of a segmented > development effort between its Cygwin and MSYS ports. > > It also doesn't really compare to Mercurial, which I personally feel is > packaged and managed a lot better. Mercurial also comes with a stable > and well supported GUI, TortoiseHg. There's also TortoiseGit, so the Windows side of things shouldn't make a difference. Not that many Pidgin developers developing on Windows... From lschiere@pidgin.im Sat Jan 15 20:46:51 2011 From: lschiere at pidgin.im (Luke Schierer) Date: Sat, 15 Jan 2011 20:46:51 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <20110115141136.4f32b6d3.morshed.nader@gmail.com> Message-ID: Status: O Content-Length: 800 Lines: 21 On Jan 15, 2011, at 20:37 EST, Eion Robb wrote: > On 16 January 2011 11:11, Nader Morshed wrote: >> For what it's worth, I would also put my support behind Mercurial. Git >> on Windows, while getting better, has a bit of a segmented >> development effort between its Cygwin and MSYS ports. >> >> It also doesn't really compare to Mercurial, which I personally feel is >> packaged and managed a lot better. Mercurial also comes with a stable >> and well supported GUI, TortoiseHg. > > There's also TortoiseGit, so the Windows side of things shouldn't make > a difference. Not that many Pidgin developers developing on > Windows... Yes, but we need to be able to support winpidgin and vulture as well, so windows client support is an important consideration. Luke From rekkanoryo@rekkanoryo.org Sat Jan 15 22:57:56 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Sat, 15 Jan 2011 22:57:56 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <20110115141136.4f32b6d3.morshed.nader@gmail.com> Message-ID: <4D326CC4.9050807@rekkanoryo.org> Status: O Content-Length: 775 Lines: 21 On 01/15/2011 08:46 PM, Luke Schierer wrote: >> There's also TortoiseGit, so the Windows side of things shouldn't make >> a difference. Not that many Pidgin developers developing on >> Windows... > > Yes, but we need to be able to support winpidgin and vulture as well, so windows client support is an important consideration. Consider Vulture dead in the water. The only activity on it in the last year was my propagating im.pidgin.pidgin to im.vulture.vulture a couple times (last done on July 2). John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rekkanoryo@rekkanoryo.org Sun Jan 16 18:03:27 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Sun, 16 Jan 2011 18:03:27 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: <4D33793F.4000801@rekkanoryo.org> Status: O Content-Length: 2213 Lines: 40 On 01/15/2011 04:22 PM, Luke Schierer wrote: >> * The Adium guys can "fork" our repo and include it in their tree as a >> subrepo if they want. The current Monotone process is painful for >> them, and using git would be only slightly less painful due to the >> increased speed. > > Most if not all of these advantages are available with git. I know that John doesn't like git, and his opinion holds more weight than mine a this point, but for what its worth, I prefer git to mercurial. For completeness, I thought I'd point out that the section of mine I preserved above about the Adium guys forking our repo is certainly possible to do with git. However, it's more difficult for them, as again they have to use a different tool just to get their branch/repo of our source. If we use Mercurial they get to take advantage of Mercurial's subrepo extension, whereby they can simply pull in the libpurple repo as a subrepo. Additionally, I don't know if this has come up in our previous discussions or not, but in git a branch is nothing more than a floating reference that always points only to the head/tip of a branch. In mercurial, a branch is part of the metadata of a given revision. In practice this means that once you commit a revision it's always on that branch. If you want git-style references you can achieve it in mercurial with the bookmarks extension. The bottom line, though, is that git and hg represent branches entirely differently, and I'd go so far as to call the git implementation of it as braindead. One argument in favor of git, however, is that git supports the concept of the author of a revision and the committer of a revision being two different people. Mercurial does not. If I use 'hg commit -u "some random person"' then there's no hint that I'm the person who actually committed the revision. I'm not sure I see this as a problem, but I imagine one or two people might object to this. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From zacwest@gmail.com Sun Jan 16 18:06:47 2011 From: zacwest at gmail.com (Zachary West) Date: Sun, 16 Jan 2011 18:06:47 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D33793F.4000801@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D33793F.4000801@rekkanoryo.org> Message-ID: Status: O Content-Length: 871 Lines: 25 On Sun, Jan 16, 2011 at 18:03, John Bailey wrote: > One argument in favor of git, however, is that git supports the concept of > the > author of a revision and the committer of a revision being two different > people. > Mercurial does not. If I use 'hg commit -u "some random person"' then > there's > no hint that I'm the person who actually committed the revision. I'm not > sure I > see this as a problem, but I imagine one or two people might object to > this. > > You could use a pushlog like so: http://hg.mozilla.org/mozilla-central/pushloghtml This records who pushes what, and I imagine something like it will eventually get added to Mercurial proper. Zachary West -------------- next part -------------- An HTML attachment was scrubbed... URL: From elb@pidgin.im Sun Jan 16 20:25:28 2011 From: elb at pidgin.im (Ethan Blanton) Date: Sun, 16 Jan 2011 20:25:28 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115183209.GC6934@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: <20110117012528.GA32293@colt> Status: O Content-Length: 1359 Lines: 29 John Bailey spake unto us the following wisdom: > It's been discussed a number of times over the last couple years that we > should consider moving away from Monotone. At this point, I'm now > inclined to agree. To that end, I propose that we move from Monotone to > Mercurial. I'll come back to this in a bit. I think most are aware of my position on this, but for the record, I am also satisfied with a move to Mercurial. I have used it on a number of other projects and for quite a few personal repositories, and it is now my DVCS of choice. I prefer the Monotone history model in a number of ways (e.g., its more complete divorce between the history graph and metadata, complete signature coverage, etc.), but Mercurial as a tool is more pleasant to use, and I do not believe that its representation shortcomings with respect to Monotone are critical. In fact, most are purely academic concerns, and will have no functional bearing on our usage. While this is my position on the issue, I am not an active developer at the moment, and it should certainly be taken with a grain of salt. Ethan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: Digital signature URL: From paul@darkrain42.org Mon Jan 17 23:35:01 2011 From: paul at darkrain42.org (Paul Aurich) Date: Mon, 17 Jan 2011 20:35:01 -0800 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115183209.GC6934@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: <4D351875.9060704@darkrain42.org> Status: O Content-Length: 1300 Lines: 39 And John Bailey spoke on 01/15/2011 10:32 AM, saying: > Hi, all, > > For almost four years now, we've been using Monotone as our source > repository. Over that time, it's proven itself to work very well for > us, I think. However, there have always been some annoyances with it. > As for my specific desire to use Mercurial, here are a few things we > gain (git may offer some or all of these as well, but I'm not > particularly fond of git, as we all know): > What do you guys say? I'm fine with anything (staying as is, or moving to Mercurial or git), with a preference for moving to a new system (and a slight preference toward Mercurial, based on the reasons outlined as well as using it recently hacking at Prosody and a few of its dependencies) That, and enough Hg<>Git conversion projects exist that contributors who would rather use Git should have an easier time of it (I could probably be convinced into setting up a cron job to automate an hg fast-export | git fast-import repo) > > John > ~Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rlaager@wiktel.com Mon Jan 17 23:55:26 2011 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 17 Jan 2011 22:55:26 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D351875.9060704@darkrain42.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D351875.9060704@darkrain42.org> Message-ID: <1295326526.23161.120.camel@watermelon.coderich.net> Status: O Content-Length: 1111 Lines: 27 On Mon, 2011-01-17 at 20:35 -0800, Paul Aurich wrote: > That, and enough Hg<>Git conversion projects exist that contributors who > would rather use Git should have an easier time of it (I could probably be > convinced into setting up a cron job to automate an hg fast-export | git > fast-import repo) Whether we go with git or hg, I'd like to provide a mirror of (at least) our trunk in the other system. My major concern with all of this is making things as easy as possible for contributors and downstream users. I like the idea of having sites like github and bitbucket available to contributors. As far as downstream users go, it seems that Mercurial is the better choice, as both Adium and Instantbird use it. That said, are we picking up a lot of patches from them? If not, they really only need a read-only clone. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ml@update.uu.se Tue Jan 18 03:40:42 2011 From: ml at update.uu.se (Marcus Lundblad) Date: Tue, 18 Jan 2011 09:40:42 +0100 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D351875.9060704@darkrain42.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D351875.9060704@darkrain42.org> Message-ID: <1295340042.2453.2.camel@sagittarius> Status: O Content-Length: 1806 Lines: 56 m?n 2011-01-17 klockan 20:35 -0800 skrev Paul Aurich: > And John Bailey spoke on 01/15/2011 10:32 AM, saying: > > Hi, all, > > > > For almost four years now, we've been using Monotone as our source > > repository. Over that time, it's proven itself to work very well for > > us, I think. However, there have always been some annoyances with it. > > > As for my specific desire to use Mercurial, here are a few things we > > gain (git may offer some or all of these as well, but I'm not > > particularly fond of git, as we all know): > > > > > What do you guys say? > > I'm fine with anything (staying as is, or moving to Mercurial or git), with > a preference for moving to a new system (and a slight preference toward > Mercurial, based on the reasons outlined as well as using it recently > hacking at Prosody and a few of its dependencies) > Personally I'd prefer git, for much the same reason as Paul prefers mercurial (using it for other projects). And as someone pointed out, github is one good reason, too. Enables contributors to share their work easily. But I'd say I wouldn't be dead-set against going with mercurial (or staying with monotone) as well. //Marcus > That, and enough Hg<>Git conversion projects exist that contributors who > would rather use Git should have an easier time of it (I could probably be > convinced into setting up a cron job to automate an hg fast-export | git > fast-import repo) > > > > > John > > > > ~Paul > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel -- Marcus Lundblad Phone +46 (0)18 250582 | Cell +46 (0)733 386299 XMPP mlundblad at jabber.org | XMPP mlundblad at gmail.com MSN ml at update.uu.se | ICQ 11604698 -- From imadil@gmail.com Tue Jan 18 14:45:52 2011 From: imadil at gmail.com (Sadrul Habib Chowdhury) Date: Tue, 18 Jan 2011 14:45:52 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D351875.9060704@darkrain42.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D351875.9060704@darkrain42.org> Message-ID: Status: O Content-Length: 731 Lines: 21 [snip] > > What do you guys say? I have been largely inactive for a while, but I'll chime in anway! :-) I am mostly OK with any choice, mtn/hg/git. I am currently familiar with mtn/git, and it doesn't appear learning hg will be too much of a trouble. I have some personal branches in mtn, and a script for migrating those into corresponding hg branches would be useful for me (I suspect for other folks as well). I am curious about the 'subrepo' thing. Would it allow someone to checkout only libpurple, for example? Can subrepos depend on each other (e.g. subrepo 'finch' depends on 'libgnt' and 'libpurple' subrepos, so that checking out 'finch' also automatically checks out 'libgnt' and 'libpurple' etc.)? Cheers. Sadrul From mark@kingant.net Tue Jan 18 18:48:21 2011 From: mark at kingant.net (Mark Doliner) Date: Tue, 18 Jan 2011 15:48:21 -0800 Subject: Time to Leave Monotone Behind? In-Reply-To: <20110115183209.GC6934@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: Status: O Content-Length: 276 Lines: 10 Thank you, John! I'm strongly in favor of switching away from Monotone to either Mercurial or Git. Both are favorites. I think I mildly prefer git, in general. But if Instantbird and Adium are both using Mercurial already, that's reason enough for me to use it. --Mark From rekkanoryo@rekkanoryo.org Wed Jan 19 00:16:48 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 19 Jan 2011 00:16:48 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <4D351875.9060704@darkrain42.org> Message-ID: <4D3673C0.40309@rekkanoryo.org> Status: O Content-Length: 3030 Lines: 79 On 01/18/2011 02:45 PM, Sadrul Habib Chowdhury wrote: > I am mostly OK with any choice, mtn/hg/git. I am currently familiar > with mtn/git, and it doesn't appear learning hg will be too much of a > trouble. I have some personal branches in mtn, and a script for > migrating those into corresponding hg branches would be useful for me > (I suspect for other folks as well). You'll find hg very familiar since you're already familiar with both mtn and git. There are a few oddities here and there, but that comes with the territory of changing tools. Mainly it's just remembering to type the right command--I often still find myself typing 'mtn' in my own hg trees. I've found it helpful to use a few extensions, too. You *should* be able to just use 'hg convert' without any special patches to do that. The convert extension should analyze your mtn database and determine what revs need to be converted, then do the conversion. Of course, you'd need to use the branchmap and authormap files from the repo I linked at the start of this thread so that the appropriate mappings happen. Otherwise you could end up duplicating a ton of history. > I am curious about the 'subrepo' thing. Would it allow someone to > checkout only libpurple, for example? Can subrepos depend on each > other (e.g. subrepo 'finch' depends on 'libgnt' and 'libpurple' > subrepos, so that checking out 'finch' also automatically checks out > 'libgnt' and 'libpurple' etc.)? The subrepo extension will recurse, to some extent. It's all handled in a versioned .hgsub file in each repo. In a subrepo setup you might have something like this: finch libgnt libpurple pidgin TopLevelRepo |-- libpurple |-- finch | `-- libgnt |-- pidgin `-- po In this case TopLevelRepo would reference libpurple, finch, pidgin, and po in its .hgsub file. The finch repo would reference libgnt in its .hgsub. When you check out TopLevelRepo, then update along a branch (say, default), hg will pull and update to specified revisions of the subrepos. (One thing I didn't realize until tonight is that subrepos don't automatically update--you have to update to a newer rev on the subrepo then commit on the parent repo to update the ref.) Now, we *could* arrange things like this: libgnt libpurple finch |-- libgnt |-- libpurple `-- po pidgin |-- libpurple `-- po po In this case, obviously there wouldn't be an all-encompassing top-level repo to contend with, but the other pitfalls still apply. Splitting out the tree into multiple repos and stitching them together as subrepos would almost necessitate that we leave our history behind and start with fresh repos. Otherwise, we'd end up with five repos that are each 215 MB, thus being far *worse* than our existing mtn setup. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rekkanoryo@rekkanoryo.org Wed Jan 19 02:02:38 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 19 Jan 2011 02:02:38 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <1295326526.23161.120.camel@watermelon.coderich.net> References: <20110115183209.GC6934@rekkanoryo.org> <4D351875.9060704@darkrain42.org> <1295326526.23161.120.camel@watermelon.coderich.net> Message-ID: <4D368C8E.3090701@rekkanoryo.org> Status: O Content-Length: 1669 Lines: 38 On 01/17/2011 11:55 PM, Richard Laager wrote: > Whether we go with git or hg, I'd like to provide a mirror of (at least) > our trunk in the other system. This probably wouldn't be a bad idea, but it might make more sense for someone who really wants such a mirror to maintain it. For example, if we move to hg, perhaps it would make more sense for Felipe to maintain a git mirror at github. That said, I don't object to running one ourselves. > My major concern with all of this is making things as easy as possible > for contributors and downstream users. I like the idea of having sites > like github and bitbucket available to contributors. While these are attractive, I also like the idea that I can say to someone "e-mail me the patches" and get a nice series of patches, without having to write (potentially) a boatload of custom lua code and instructing people how to use it in their .monotonerc's. This is yet another benefit we get with either hg or git. > As far as downstream users go, it seems that Mercurial is the better > choice, as both Adium and Instantbird use it. That said, are we picking > up a lot of patches from them? If not, they really only need a read-only > clone. We've picked up a few patches from both. I've personally picked up more from Instantbird, by virtue of Florian opening tickets on trac. Evan tends to upstream Adium libpurple patches himself. :) John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rekkanoryo@rekkanoryo.org Wed Jan 19 02:16:53 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 19 Jan 2011 02:16:53 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> Message-ID: <4D368FE5.50503@rekkanoryo.org> Status: O Content-Length: 2963 Lines: 60 On 01/18/2011 06:48 PM, Mark Doliner wrote: > Thank you, John! No problem. If the conversion wouldn't take so long, this would be much less painful. The last conversion I ran took almost 27 hours. I need to see if I can more invasively patch the hg 'convert' extension to use mtn's automate stdio stuff instead of using individual mtn calls. This could improve performance if one long-lived mtn automate process served all the requests, compared to at least two mtn automate processes per revision. I imagine I could also use 'mtn git_export' and then pipe this into the fast-import extension for hg, but this would defeat some of the stuff Richard recently committed to the conversion files repo I linked at the beginning of this thread. I patched hg convert to handle a "committer" cert in the mtn database, as well as combining comment certs into the changelog entry like the git_export stuff does. The committer cert, where it exists and isn't the same as the author cert, is appended to the changelog since hg has no concept of committer and author being different people. Appending the committer to the changelog in this manner is a precedent set by hg convert's own git support and some tools like hgk support it. I'd like to note that I still need to track down the few leftover revisions with multiple changelog certs. I know there are a few left from some of us (myself included) wanting to add additional information to the changelog post-commit. The conversion process will lose all but one changelog cert, near as I can tell. I'd like to reconcile the multiple changelog certs to include all the information so a conversion looks as good as we can possibly make it. > I'm strongly in favor of switching away from Monotone to either > Mercurial or Git. Both are favorites. I think I mildly prefer git, > in general. But if Instantbird and Adium are both using Mercurial > already, that's reason enough for me to use it. Ok, so to summarize, the replies so far indicate: * 3 developers who have expressed preference for hg * 1 of these developers dislikes git * 0 of these developers object to git * 3 developers who have expressed preference for git * 2 of these developers support hg to assist downstream projects * 0 of these developers object to hg * 1 developer who has expressed no preference * 1 downstream project that would prefer hg * 1 Crazy Patch Writer who has expressed preference for hg Is this accurate? And would anyone else like to weigh in on this? Based solely on what's been posted here on the list, it's feeling like more or less a draw, with the benefit to Adium and Instantbird pushing toward hg somewhat. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From kstange@pidgin.im Wed Jan 19 03:00:21 2011 From: kstange at pidgin.im (Kevin Stange) Date: Wed, 19 Jan 2011 02:00:21 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D368FE5.50503@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: <4D369A15.406@pidgin.im> Status: O Content-Length: 964 Lines: 24 On 01/19/2011 01:16 AM, John Bailey wrote: > Is this accurate? And would anyone else like to weigh in on this? Based solely > on what's been posted here on the list, it's feeling like more or less a draw, > with the benefit to Adium and Instantbird pushing toward hg somewhat. This is more or less just a noisy no-op, but I have no particular objection to either and don't use the tools enough recently that my opinion is important to this discussion. :) I have used not used hg at all, and I have used git very little. My experience with git was not unpleasant, though I am not terribly fond of browsing git repos via gitweb. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From evan.s@dreskin.net Wed Jan 19 08:33:09 2011 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 19 Jan 2011 07:33:09 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D368FE5.50503@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: <89838996-1B42-436C-96F1-5D0F00985DD0@dreskin.net> Status: O Content-Length: 651 Lines: 10 On Jan 19, 2011, at 1:16 AM, John Bailey wrote: > Is this accurate? And would anyone else like to weigh in on this? Based solely > on what's been posted here on the list, it's feeling like more or less a draw, > with the benefit to Adium and Instantbird pushing toward hg somewhat. Unsurprisingly, I weigh in gently on the side of hg. :). Getting to use a subrepo rather than a separate tool/separate checkout/separate modality would be nice for Adium; however, it's ultimately a convenience for us that is much less a major factor than the primary day-to-day libpurple/pidgin/finch developers' preferences. -Evan From grim@reaperworld.com Wed Jan 19 09:34:58 2011 From: grim at reaperworld.com (Gary Kramlich) Date: Wed, 19 Jan 2011 08:34:58 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D368FE5.50503@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: <4D36F692.2050108@reaperworld.com> Status: O Content-Length: 530 Lines: 14 On 01/19/2011 01:16 AM, John Bailey wrote: > Is this accurate? And would anyone else like to weigh in on this? > Based solely > on what's been posted here on the list, it's feeling like more or less a draw, > with the benefit to Adium and Instantbird pushing toward hg somewhat. Sure, I'll chime in, although we all know how active I've been... anyways, hg all the way. I've never used git for anything I've worked on, but mercurial just seems to work great for me :) > John > -- Gary Kramlich From salinasv@gmail.com Wed Jan 19 09:58:36 2011 From: salinasv at gmail.com (=?UTF-8?Q?Jorge_Villase=C3=B1or?=) Date: Wed, 19 Jan 2011 08:58:36 -0600 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D368FE5.50503@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: Status: O Content-Length: 600 Lines: 17 On Wed, Jan 19, 2011 at 1:16 AM, John Bailey wrote: > Is this accurate? ?And would anyone else like to weigh in on this? ?Based solely > on what's been posted here on the list, it's feeling like more or less a draw, > with the benefit to Adium and Instantbird pushing toward hg somewhat. I have no preference between git and hg and I'm all in for getting out of mtn. -- Masca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From daniel.atallah@gmail.com Wed Jan 19 12:54:12 2011 From: daniel.atallah at gmail.com (Daniel Atallah) Date: Wed, 19 Jan 2011 12:54:12 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D368FE5.50503@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: Status: O Content-Length: 352 Lines: 11 On Wed, Jan 19, 2011 at 02:16, John Bailey wrote: > Is this accurate? ?And would anyone else like to weigh in on this? ?Based solely > on what's been posted here on the list, it's feeling like more or less a draw, > with the benefit to Adium and Instantbird pushing toward hg somewhat. I'm also a +1 on Hg, FWIW. -D From qulogic@pidgin.im Wed Jan 19 15:30:47 2011 From: qulogic at pidgin.im (Elliott Sales de Andrade) Date: Wed, 19 Jan 2011 15:30:47 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: Status: O Content-Length: 671 Lines: 24 On Wed, Jan 19, 2011 at 12:54 PM, Daniel Atallah wrote: > On Wed, Jan 19, 2011 at 02:16, John Bailey wrote: > >> Is this accurate? ?And would anyone else like to weigh in on this? ?Based solely >> on what's been posted here on the list, it's feeling like more or less a draw, >> with the benefit to Adium and Instantbird pushing toward hg somewhat. > > I'm also a +1 on Hg, FWIW. > I'll +1 on hg also. Though I'm not really soured on mtn, I understand the downsides WRT downstream and casual contributors, so I don't mind if we decide to move away from it. > -D > -- Elliott aka QuLogic Pidgin developer From felipe.contreras@gmail.com Wed Jan 19 18:17:12 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 20 Jan 2011 01:17:12 +0200 Subject: Mercurial vs Git Message-ID: Status: O Content-Length: 3259 Lines: 103 Hi, So you are thinking on switching away from monotone, that's great. As you might know, I am extremely familiar with Git, as I'm a contributor, and I've analyzed Mercurial for the sake of comparison[2]. Mercurial doesn't have most of the disadvantages I listed on the "Monotone analysis", in fact, to me it's very similar to git. However, there's a big difference: branches. == branches == In git, branches are distributed, which means that if you have 2 developers with 2 branches each, that doesn't mean that by sharing their repos, they would have 4 branches. 'git branch -a' would show: origin/master darkrain/master darkrain/buddy-add darkrain/docs khc/master khc/msnp14 khc/msnp14.ticket393 (This is similar to what mercurial bookmarks extension would show, except that the 'khc/' prefix would not be there.) IOW; not everyone has to see the branches of everyone, you manually add which repositories you want to follow, and when you do 'git fetch', you would see the branches in that particular repository updated. And of course, branches are disposable (supposing I'm 'darkrain'): git checkout master git merge docs # the commit would say 'Merge branch 'docs' into master git push origin master # push the 'master' branch to the 'origin' repo git branch -d docs # delete this branch which won't be used any more If for some reason you want everyone to see your branch: git push origin docs:darkrain.docs # pushes the local docs branch as 'darkrain.docs' to 'origin' This is why it's possible in the linux kernel to have hundreds of maintainer repositories, each one with dozens of branches and patches coming from the branches of even more developers. Branches are merely a utility to identify commits. I haven't seen anyone discuss this fact, except John Bailey who called the git implementation 'braindead' without going into any details. == graft points == I saw a proposal from John Bailey to have a structure like: libgnt libpurple finch |-- libgnt |-- libpurple `-- po pidgin |-- libpurple `-- po po The disadvantage, he claimed, is that the history would have to start from zero since otherwise each one of these repos would have to be 215 MB. Not with git. My proposal would be the following. Convert the whole history to git, then, make a new release, say 2.8 where the directories are split (libpurple, pidgin, etc.). That repository would be the legacy one, then, start new separate repositories that start from scratch. Then, for the people that want to have the full history, they can setup a graft-point[3] and voil?; the full history would be available on each one of the repos. == Mercurial side projects == No biggie, it's easy to convert form hg to git, so the hg version can be offered as well. In conclusion, everything that can be done with Mercurial can be done with Git, but not the other way around (at least I'm pretty sure about the branches). Therefore, the sensible choice IMO is Git. I'm not subscribed to the list, so please 'reply-to-all'. Cheers. [1] http://pidgin.im/pipermail/devel/2008-July/006308.html [2] http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ [3] https://git.wiki.kernel.org/index.php/GraftPoint -- Felipe Contreras From rlaager@wiktel.com Wed Jan 19 21:24:46 2011 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 19 Jan 2011 20:24:46 -0600 Subject: Mercurial vs Git In-Reply-To: References: Message-ID: <1295490286.3016.106.camel@watermelon.coderich.net> Status: O Content-Length: 1833 Lines: 59 On Thu, 2011-01-20 at 01:17 +0200, Felipe Contreras wrote: > And of course, branches are disposable (supposing I'm 'darkrain'): > > git checkout master > git merge docs # the commit would say 'Merge branch 'docs' into master > git push origin master # push the 'master' branch to the 'origin' repo > git branch -d docs # delete this branch which won't be used any more Let's suppose that the tip of Pidgin's main line of development (trunk/master/etc.) is revision A1. I make a branch, called "rlaager/foo" (or rlaager.foo or rlaager-foo), of A1. I commit a change, revision B1. Then I commit another change, B2. Meanwhile, someone on trunk commits A2 and A3. So we have this: A1 | \ A2 B2 | | A3 B3 Conceptually, we developers think of A1..A3 as the trunk, and A1..B3 as the "rlaager/foo" branch. So far, none of these concepts should vary with any [D]VCS that supports branching. Now, imagine I merge B3 back into "trunk" to get A4: A1 | \ A2 B2 | | A3 B3 | / | / |/ A4 This merge is possible in git, hg, and other [D]VCSes not relevant here. Now, assuming I push this to our central repository in the "usual way" for git/hg, if John looks at the history, is there a way for him to identify that B2 and B3 were part of the "rlaager/foo" branch? As I understand it, with Mercurial, B2 and B3 would be (immutably, I think) marked as having been a part of the "rlaager/foo" branch, so the answer would be yes. As I understand it, in git, branches are basically mutable tags, so the answer would be no. Is this correct? Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ecoffey@gmail.com Wed Jan 19 22:13:16 2011 From: ecoffey at gmail.com (Eoin Coffey) Date: Wed, 19 Jan 2011 20:13:16 -0700 Subject: Mercurial vs Git In-Reply-To: <1295490286.3016.106.camel@watermelon.coderich.net> References: <1295490286.3016.106.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 4236 Lines: 140 I took the liberty of illustrating this on github. Mostly for my benefit, since your conclusion seemed wrong, but I couldn't be sure until I walked through it :-P In short: Yes they will see your history, but not necessarily your branch. I followed your example and it lives at : https://github.com/ecoffey/pidgin-illustration You'll notice https://github.com/ecoffey/pidgin-illustration/branches only lists master, but https://github.com/ecoffey/pidgin-illustration/network shows all the 'B*' commits happening in a second line of commits and then the merge. So yeah the branch rlaager-foo is just a pointer to a commit; And to push the "branch" (which is the set of 'B*' commits) you do not need to push the handy label that points to the head of that branch. Which almost kind of makes sense! And here is what I did at the command line to reproduce this in git: mkdir pidgin-illustration; cd pidgin-illustration git init touch A1.txt git add A1.txt ; git commit -m 'A1' git push origin master git checkout -b rlaager-foo # this creates the branch and switches to it touch B1.txt; git add B1.txt ; git commit -m 'B1' # Repeat above for B2, B3 git checkout master # Repeat touch, add, commit for A2, A3 And then finally: ecoffey at aenea : ~/Code/pidgin-illustration $ git branch * master rlaager-foo ecoffey at aenea : ~/Code/pidgin-illustration $ git merge rlaager-foo --no-ff Merge made by recursive. 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 B1.txt create mode 100644 B2.txt create mode 100644 B3.txt ecoffey at aenea : ~/Code/pidgin-illustration $ git log -n 1 commit 6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 Merge: e9e3659 ecf1201 Author: Eoin Coffey Date: Wed Jan 19 20:00:27 2011 -0700 Merge branch 'rlaager-foo' ecoffey at aenea : ~/Code/pidgin-illustration $ git push origin Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (12/12), 1.01 KiB, done. Total 12 (delta 6), reused 0 (delta 0) To git at github.com:ecoffey/pidgin-illustration.git c4c7b1d..6fc76c5 master -> master I used the --no-ff option to specify that git should do a 'fast forward' merge. This makes sure a individual merge commit is generated to match the example you were describing. Anyways, hope that helps. -Eoin On Wed, Jan 19, 2011 at 7:24 PM, Richard Laager wrote: > On Thu, 2011-01-20 at 01:17 +0200, Felipe Contreras wrote: >> And of course, branches are disposable (supposing I'm 'darkrain'): >> >> ?git checkout master >> ?git merge docs # the commit would say 'Merge branch 'docs' into master >> ?git push origin master # push the 'master' branch to the 'origin' repo >> ?git branch -d docs # delete this branch which won't be used any more > > Let's suppose that the tip of Pidgin's main line of development > (trunk/master/etc.) is revision A1. > > I make a branch, called "rlaager/foo" (or rlaager.foo or rlaager-foo), > of A1. I commit a change, revision B1. Then I commit another change, B2. > Meanwhile, someone on trunk commits A2 and A3. So we have this: > > A1 > | ?\ > A2 ?B2 > | ? ?| > A3 ?B3 > > Conceptually, we developers think of A1..A3 as the trunk, and A1..B3 as > the "rlaager/foo" branch. So far, none of these concepts should vary > with any [D]VCS that supports branching. > > Now, imagine I merge B3 back into "trunk" to get A4: > > A1 > | ?\ > A2 ?B2 > | ? ?| > A3 ?B3 > | ?/ > | / > |/ > A4 > > This merge is possible in git, hg, and other [D]VCSes not relevant here. > > Now, assuming I push this to our central repository in the "usual way" > for git/hg, if John looks at the history, is there a way for him to > identify that B2 and B3 were part of the "rlaager/foo" branch? > > As I understand it, with Mercurial, B2 and B3 would be (immutably, I > think) marked as having been a part of the "rlaager/foo" branch, so the > answer would be yes. > > As I understand it, in git, branches are basically mutable tags, so the > answer would be no. Is this correct? > > Richard > > _______________________________________________ > Devel mailing list > Devel at pidgin.im > http://pidgin.im/cgi-bin/mailman/listinfo/devel > > From rekkanoryo@rekkanoryo.org Wed Jan 19 22:56:39 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Wed, 19 Jan 2011 22:56:39 -0500 Subject: Mercurial vs Git In-Reply-To: References: Message-ID: <4D37B277.5050202@rekkanoryo.org> Status: O Content-Length: 4914 Lines: 107 On 01/19/2011 06:17 PM, Felipe Contreras wrote: > This is why it's possible in the linux kernel to have hundreds of maintainer > repositories, each one with dozens of branches and patches coming from the > branches of even more developers. Branches are merely a utility to identify > commits. That's great for projects that operate in that manner, like the kernel. For our practices, I think a more "traditional" branching model where a branch is more than just a floating reference is more appropriate. Now, for some clarification, in the branch flow you described there, you get nearly identical behavior with monotone if Richard's branch is not included in the branch pattern pushed to a different database. You end up with the revisions because they're needed as part of the history, but you don't get the branch certs because the branch's name didn't match the push pattern. For a concrete example, if you look carefully in our monotone database, you'll find a number of revisions from the maemo guy that have no branch certs. > I haven't seen anyone discuss this fact, except John Bailey who called the git > implementation 'braindead' without going into any details. Perhaps "braindead" was a poor choice of words. But I don't like the idea of the "branch" being a floating reference to the head of a portion of the revision graph. Our branches generally are larger feature branches, where (in my opinion) it's more useful to always have those revisions tied to a given branch. It's not the immutability of the branch that I'm going for here, more the fact that *each* revision on the branch is *explicitly* on the branch, not implicitly by walking the history graph if the branch ref is present. > > == graft points == > > I saw a proposal from John Bailey to have a structure like: > > libgnt > libpurple > finch > |-- libgnt > |-- libpurple > `-- po > pidgin > |-- libpurple > `-- po > po > > The disadvantage, he claimed, is that the history would have to start from zero > since otherwise each one of these repos would have to be 215 MB. Note that this wasn't directly a proposal. It was mostly intended as an illustration in response to Sadrul's question about how the subrepos worked. The size of each repo being 215 MB was assuming we wanted to retain history in *all* the repos, which I admittedly should have made clear in the first place. For some sections of the tree, for example the 'po' directory, I'm not sure the history has any intrinsic value. Where the history doesn't have enough value for us to care about, throwing the history away and starting over is trivial and would reduce the size of the collection of repos. Also, I'm not an expert on the 'hg convert' tool, so it's possible there's additional functionality therein that I don't know about that could assist in, or completely handle, slicing and dicing the history appropriately. > Not with git. > > My proposal would be the following. Convert the whole history to git, then, > make a new release, say 2.8 where the directories are split (libpurple, pidgin, > etc.). That repository would be the legacy one, then, start new separate > repositories that start from scratch. As a concept, this particular proposal has merit. A lot of merit, in my opinion. I'd propose that if we want to move away from the single-repo model we make 2.8.x the end of the line for both one-repo and 2.x. Then for 3.0.0 we create whatever arrangement of repositories we feel is appropriate (I'd say libpurple, libgnt, finch, pidgin, and po if we don't split the po's into each repo) with all the subrepo glue we want/need and start anew, referring to the old repo if we need history. > Then, for the people that want to have the full history, they can setup a > graft-point[3] and voil?; the full history would be available on each one of the > repos. This is an interesting feature that some may find useful. That said, the Adium guys have done pretty well without such functionality in their new "each branch is a repo" model. It does make me wonder how difficult writing such an extension for mercurial would be, though. > In conclusion, everything that can be done with Mercurial can be done with > Git, but not the other way around (at least I'm pretty sure about the > branches). Therefore, the sensible choice IMO is Git. Perhaps git seems reasonable to you. Whether it's reasonable for us or not remains to be seen. The recent votes to come in are making our decision lean toward hg. If the consensus is to move to hg, that's where we'll go. Likewise, if the consensus is git, that's where we'll go, as much as it displeases me. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From evan.s@dreskin.net Wed Jan 19 23:16:12 2011 From: evan.s at dreskin.net (Evan Schoenberg, M.D.) Date: Wed, 19 Jan 2011 22:16:12 -0600 Subject: Mercurial vs Git In-Reply-To: <4D37B277.5050202@rekkanoryo.org> References: <4D37B277.5050202@rekkanoryo.org> Message-ID: Status: O Content-Length: 815 Lines: 16 On Jan 19, 2011, at 9:56 PM, John Bailey wrote: >> Then, for the people that want to have the full history, they can setup a >> graft-point[3] and voil?; the full history would be available on each one of the >> repos. > > This is an interesting feature that some may find useful. That said, the Adium > guys have done pretty well without such functionality in their new "each branch > is a repo" model. It does make me wonder how difficult writing such an > extension for mercurial would be, though. Specifically, the utility of deep history earlier than the current major branch is minimal in most cases; it should always be available in some way, but providing it at all times to each developer with every checkout is certainly overkill if avoiding doing so is easy or provides other conveniences. -Evan From felipe.contreras@gmail.com Thu Jan 20 05:35:26 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 20 Jan 2011 12:35:26 +0200 Subject: Mercurial vs Git In-Reply-To: <4D37B277.5050202@rekkanoryo.org> References: <4D37B277.5050202@rekkanoryo.org> Message-ID: Status: O Content-Length: 6613 Lines: 165 On Thu, Jan 20, 2011 at 5:56 AM, John Bailey wrote: > On 01/19/2011 06:17 PM, Felipe Contreras wrote: >> This is why it's possible in the linux kernel to have hundreds of maintainer >> repositories, each one with dozens of branches and patches coming from the >> branches of even more developers. Branches are merely a utility to identify >> commits. > > That's great for projects that operate in that manner, like the kernel. ?For our > practices, I think a more "traditional" branching model where a branch is more > than just a floating reference is more appropriate. Why? How exactly would a floating reference affect your project negatively? > Now, for some clarification, in the branch flow you described there, you get > nearly identical behavior with monotone if Richard's branch is not included in > the branch pattern pushed to a different database. ?You end up with the > revisions because they're needed as part of the history, but you don't get the > branch certs because the branch's name didn't match the push pattern. ?For a > concrete example, if you look carefully in our monotone database, you'll find a > number of revisions from the maemo guy that have no branch certs. And that demonstrates one of the many design inconsistencies about this model. 1) commits can be part of no branch, even though they are parents of a commit in the main branch A | \ B C A (master), B (master), C (nowhere) 2) branches can follow weird patterns A (master) | B (test) | C (master) | D (test) 3) branches can be scattered A B * | / C F * | / D E | / G * B, F, G = (test) The only thing that prevents those inconsistencies is the front-end app (does it?). With the git model, those things are impossible. And you would see from which branch the commits came from: Merge branch 'rlaager-foo' https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 >> I haven't seen anyone discuss this fact, except John Bailey who called the git >> implementation 'braindead' without going into any details. > > Perhaps "braindead" was a poor choice of words. ?But I don't like the idea of > the "branch" being a floating reference to the head of a portion of the revision > graph. > > Our branches generally are larger feature branches, where (in my opinion) it's > more useful to always have those revisions tied to a given branch. ?It's not the > immutability of the branch that I'm going for here, more the fact that *each* > revision on the branch is *explicitly* on the branch, not implicitly by walking > the history graph if the branch ref is present. Yes, but why? The git model would represent exactly the same thing, unless you want some representation in which not all the commits ancestor of a branch head are part of the branch, in which case it's not what people call a branch, but more like "commit labels", and I still don't see why you would prefer those. >> == graft points == >> >> I saw a proposal from John Bailey to have a structure like: >> >> libgnt >> libpurple >> finch >> ?|-- libgnt >> ?|-- libpurple >> ?`-- po >> pidgin >> ?|-- libpurple >> ?`-- po >> po >> >> The disadvantage, he claimed, is that the history would have to start from zero >> since otherwise each one of these repos would have to be 215 MB. > > Note that this wasn't directly a proposal. ?It was mostly intended as an > illustration in response to Sadrul's question about how the subrepos worked. > > The size of each repo being 215 MB was assuming we wanted to retain history in > *all* the repos, which I admittedly should have made clear in the first place. > For some sections of the tree, for example the 'po' directory, I'm not sure the > history has any intrinsic value. ?Where the history doesn't have enough value > for us to care about, throwing the history away and starting over is trivial and > would reduce the size of the collection of repos. It was clear to me, that's why I said it would have to start from zero, or the size would be 215 MB. > Also, I'm not an expert on the 'hg convert' tool, so it's possible there's > additional functionality therein that I don't know about that could assist in, > or completely handle, slicing and dicing the history appropriately. I don't know how that's possible, or beneficial. If you go back to say v2.7.9, you would want to see what is currently in mtn, not some sliced uncompilable collection of files. >> Not with git. >> >> My proposal would be the following. Convert the whole history to git, then, >> make a new release, say 2.8 where the directories are split (libpurple, pidgin, >> etc.). That repository would be the legacy one, then, start new separate >> repositories that start from scratch. > > As a concept, this particular proposal has merit. ?A lot of merit, in my > opinion. ?I'd propose that if we want to move away from the single-repo model we > make 2.8.x the end of the line for both one-repo and 2.x. ?Then for 3.0.0 we > create whatever arrangement of repositories we feel is appropriate (I'd say > libpurple, libgnt, finch, pidgin, and po if we don't split the po's into each > repo) with all the subrepo glue we want/need and start anew, referring to the > old repo if we need history. > >> Then, for the people that want to have the full history, they can setup a >> graft-point[3] and voil?; the full history would be available on each one of the >> repos. > > This is an interesting feature that some may find useful. ?That said, the Adium > guys have done pretty well without such functionality in their new "each branch > is a repo" model. ?It does make me wonder how difficult writing such an > extension for mercurial would be, though. No idea, perhaps there is already one, but my intuition tells me it's not possible with an extension, the core would have to support this. >> In conclusion, everything that can be done with Mercurial can be done with >> Git, but not the other way around (at least I'm pretty sure about the >> branches). Therefore, the sensible choice IMO is Git. > > Perhaps git seems reasonable to you. ?Whether it's reasonable for us or not > remains to be seen. ?The recent votes to come in are making our decision lean > toward hg. ?If the consensus is to move to hg, that's where we'll go. ?Likewise, > if the consensus is git, that's where we'll go, as much as it displeases me. Sure, I haven't plotted the votes closely, but from what I recall most of the votes where git/hg (slightly favoring one or the other), or don't care. I don't recall anyone saying definitely no to git. Cheers. -- Felipe Contreras From felipe.contreras@gmail.com Thu Jan 20 05:53:34 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 20 Jan 2011 12:53:34 +0200 Subject: Mercurial vs Git In-Reply-To: References: <4D37B277.5050202@rekkanoryo.org> Message-ID: Status: O Content-Length: 1650 Lines: 34 On Thu, Jan 20, 2011 at 12:35 PM, Felipe Contreras wrote: > On Thu, Jan 20, 2011 at 5:56 AM, John Bailey wrote: >>> I haven't seen anyone discuss this fact, except John Bailey who called the git >>> implementation 'braindead' without going into any details. >> >> Perhaps "braindead" was a poor choice of words. ?But I don't like the idea of >> the "branch" being a floating reference to the head of a portion of the revision >> graph. >> >> Our branches generally are larger feature branches, where (in my opinion) it's >> more useful to always have those revisions tied to a given branch. ?It's not the >> immutability of the branch that I'm going for here, more the fact that *each* >> revision on the branch is *explicitly* on the branch, not implicitly by walking >> the history graph if the branch ref is present. > > Yes, but why? The git model would represent exactly the same thing, > unless you want some representation in which not all the commits > ancestor of a branch head are part of the branch, in which case it's > not what people call a branch, but more like "commit labels", and I > still don't see why you would prefer those. Another point I forgot to mention is that in my experience "large feature" branches can be (and usually are) composed of many small feature branches (at least in git). And to me, it makes perfect sense that when branch 'small-feature-y' is merged into the 'large-feature-x' branch, all the commits in the small branch can be considered now part of the large branch. That's exactly how the git model represents this. -- Felipe Contreras From rlaager@wiktel.com Thu Jan 20 11:11:19 2011 From: rlaager at wiktel.com (Richard Laager) Date: Thu, 20 Jan 2011 10:11:19 -0600 Subject: Mercurial vs Git In-Reply-To: References: <4D37B277.5050202@rekkanoryo.org> Message-ID: <1295539879.3016.444.camel@watermelon.coderich.net> Status: O Content-Length: 1728 Lines: 39 On Thu, 2011-01-20 at 12:35 +0200, Felipe Contreras wrote: > On Thu, Jan 20, 2011 at 5:56 AM, John Bailey wrote: > > On 01/19/2011 06:17 PM, Felipe Contreras wrote: > >> This is why it's possible in the linux kernel to have hundreds of maintainer > >> repositories, each one with dozens of branches and patches coming from the > >> branches of even more developers. Branches are merely a utility to identify > >> commits. > > > > That's great for projects that operate in that manner, like the kernel. For our > > practices, I think a more "traditional" branching model where a branch is more > > than just a floating reference is more appropriate. > > Why? How exactly would a floating reference affect your project negatively? It wouldn't. It's the lack of a non-floating branch identifier that John doesn't like. Mercurial has both (bookmarks and branches); git only has one. > And you would see from which branch the commits came from: > Merge branch 'rlaager-foo' > https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 I asked how you would tell for revision B1, B2, or B3, not for the A4 merge. That said, I think your points about the inconsistencies are sound. Even with MTN now, we can still end up with revisions on trunk that don't have branch information, so I don't see any reason to worry about this branching difference that much either way. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From felipe.contreras@gmail.com Thu Jan 20 12:08:20 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 20 Jan 2011 19:08:20 +0200 Subject: Mercurial vs Git In-Reply-To: <1295539879.3016.444.camel@watermelon.coderich.net> References: <4D37B277.5050202@rekkanoryo.org> <1295539879.3016.444.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 2851 Lines: 79 On Thu, Jan 20, 2011 at 6:11 PM, Richard Laager wrote: > On Thu, 2011-01-20 at 12:35 +0200, Felipe Contreras wrote: >> On Thu, Jan 20, 2011 at 5:56 AM, John Bailey wrote: >> > On 01/19/2011 06:17 PM, Felipe Contreras wrote: >> >> This is why it's possible in the linux kernel to have hundreds of maintainer >> >> repositories, each one with dozens of branches and patches coming from the >> >> branches of even more developers. Branches are merely a utility to identify >> >> commits. >> > >> > That's great for projects that operate in that manner, like the kernel. ?For our >> > practices, I think a more "traditional" branching model where a branch is more >> > than just a floating reference is more appropriate. >> >> Why? How exactly would a floating reference affect your project negatively? > > It wouldn't. It's the lack of a non-floating branch identifier that John > doesn't like. Mercurial has both (bookmarks and branches); git only has > one. That doesn't answer the question: How would a "lack of non-floating branch identifier" affect the project negatively? "John doesn't like it" is a non-answer... Why? >> And you would see from which branch the commits came from: >> Merge branch 'rlaager-foo' >> https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 > > I asked how you would tell for revision B1, B2, or B3, not for the A4 > merge. All you need is the merge. The merge tells you the name of the branch, the actual branch (the commits) being merged, and the branch being merged to. Graphically, you can see that all the information is there: % git log --oneline --decorate --graph * 6fc76c5 (HEAD, origin/master, origin/HEAD, master) Merge branch 'rlaager-foo' |\ | * ecf1201 B3 | * 0d87796 B2 | * 4174bf8 B1 * | e9e3659 A3 * | 6411aea A2 |/ * c4c7b1d A1 commit And you can make a simple query: what are the commits on the merged branch of 'master' (A4), that were not part of master before the merge? % git log --oneline --decorate --graph master^1..master^2 * ecf1201 B3 * 0d87796 B2 * 4174bf8 B1 Isn't that exactly what you wanted? master^1 is the original branch (A3), master^2 is the merged branch (B3), and master^1..master^2 are the commits of master^2 that are not in master^1. Isn't git cool? :) > That said, I think your points about the inconsistencies are sound. Even > with MTN now, we can still end up with revisions on trunk that don't > have branch information, so I don't see any reason to worry about this > branching difference that much either way. Sure, it's not something that would handicap you in any way, but still, I think the database model doesn't coincide with the 'branch' mental model, and that has implications on usability that you might not realize now. Cheers. -- Felipe Contreras From felipe.contreras@gmail.com Thu Jan 20 12:21:36 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Thu, 20 Jan 2011 19:21:36 +0200 Subject: Mercurial vs Git In-Reply-To: References: <1295490286.3016.106.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 1171 Lines: 30 On Thu, Jan 20, 2011 at 5:13 AM, Eoin Coffey wrote: > I took the liberty of illustrating this on github. ?Mostly for my > benefit, since your conclusion seemed wrong, but I couldn't be sure > until I walked through it :-P > > In short: Yes they will see your history, but not necessarily your branch. > > I followed your example and it lives at : > https://github.com/ecoffey/pidgin-illustration Thanks for this example, it has been very useful :) > I used the --no-ff option to specify that git should do a 'fast > forward' merge. ?This makes sure a individual merge commit is > generated to match the example you were describing. It's the other way around; --no-ff specifies that git should _not_ do a fast-forward merge. But in fact, in this particular case it's not needed to specify that, because a fast-forward merge cannot be made unless the base of the branch to be merged is the same as the tip of the branch to merge to (you can ff merge to A1, but not A3). In order to do a fast-forward merge you would need to rebase rlaager-foo to master first (A3); then the branch base of rlaager-foo would be A3. Cheers. -- Felipe Contreras From ecoffey@gmail.com Thu Jan 20 12:33:04 2011 From: ecoffey at gmail.com (Eoin Coffey) Date: Thu, 20 Jan 2011 10:33:04 -0700 Subject: Mercurial vs Git In-Reply-To: References: <1295490286.3016.106.camel@watermelon.coderich.net> Message-ID: Status: O Content-Length: 1572 Lines: 44 On Thu, Jan 20, 2011 at 10:21 AM, Felipe Contreras wrote: > On Thu, Jan 20, 2011 at 5:13 AM, Eoin Coffey wrote: >> I took the liberty of illustrating this on github. ?Mostly for my >> benefit, since your conclusion seemed wrong, but I couldn't be sure >> until I walked through it :-P >> >> In short: Yes they will see your history, but not necessarily your branch. >> >> I followed your example and it lives at : >> https://github.com/ecoffey/pidgin-illustration > > Thanks for this example, it has been very useful :) Awesome :-) > >> I used the --no-ff option to specify that git should do a 'fast >> forward' merge. ?This makes sure a individual merge commit is >> generated to match the example you were describing. > > It's the other way around; --no-ff specifies that git should _not_ do > a fast-forward merge. But in fact, in this particular case it's not > needed to specify that, because a fast-forward merge cannot be made > unless the base of the branch to be merged is the same as the tip of > the branch to merge to (you can ff merge to A1, but not A3). In order > to do a fast-forward merge you would need to rebase rlaager-foo to > master first (A3); then the branch base of rlaager-foo would be A3. In my mind I was saying 'should not', guess the 'not' didn't make it to the keyboard :-P I included that in the merge command, and called it out here because I wanted to be very explicit and make sure I was generating the history Richard had described. > > Cheers. > > -- > Felipe Contreras > From rekkanoryo@rekkanoryo.org Thu Jan 20 21:31:26 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Thu, 20 Jan 2011 21:31:26 -0500 Subject: Mercurial vs Git In-Reply-To: References: <4D37B277.5050202@rekkanoryo.org> Message-ID: <4D38EFFE.7050704@rekkanoryo.org> Status: O Content-Length: 4260 Lines: 81 On 01/20/2011 05:35 AM, Felipe Contreras wrote: > Why? How exactly would a floating reference affect your project negatively? It doesn't affect the project negatively, but it makes a specific scenario I've run into before inconvenient for me. Regardless of how git, hg, mtn, or any other random SCM handles branches, one simple fact does not change. I did *not* work on "master" or "default" or whatever branch name when I was working on, say, a yahoo17 branch. Yes, the net effect after a merge is that the *sum* of the branch is on "default", but the individual revisions were *not* when they were created. This is an important distinction to me, because now I can prove to $random_annoying_user that "bug X never existed on default because I both introduced and fixed it on yahoo17 before it was merged." If I have to track down the commit message of the merge, then walk the graph backward and guess what branch revisions ABC and XYZ are on based solely on the appearance of the graph, this becomes more of a pain than I'm willing to tolerate. Even if the tool can figure this out for me, I still consider it a deficiency in the design. Now I'm sure you'll make some argument about "it's your branch; you'll have the ref to the head of the branch if you didn't delete it", but that argument completely falls apart if I'm proving this for a branch I never worked on and never explicitly pulled that ended up on default/master/whatever. It also falls apart if I work from three different working copies on three different machines without pushing/pulling changes among them, which I've done on more than one occasion--I could be on a machine that doesn't have this all-important floating ref. The bottom line is that in my opinion the git model of allowing the removal of the branch ref and thus "collapsing" the "branch" into whatever it was merged into leads to an inaccurate view of the history that I'm not happy about. Yes, it's obvious from this statement that I don't follow the development model git users do. It's pointless debating this any further (and in fact, further messages on this topic *will* be ignored), because you're not going to convince me that I'm wrong anymore than I'm going to be able to convince you that you're wrong. I have far more important things to spend my time and energy on. > And that demonstrates one of the many design inconsistencies about this model. > > 1) commits can be part of no branch, even though they are parents of > a commit in the main branch > The only thing that prevents those inconsistencies is the front-end > app (does it?). With the git model, those things are impossible. If you want it to be impossible in monotone, you can force it to be impossible by leveraging the lua extensibility in .monotonerc. Simply walk the graph and manually "collapse" it into the target branch by issuing branch certs that force those revisions onto the appropriate branch. The lack of a branch certificate is not an inconsistency--it's simply saying "this revision came from outside our normal world view." That said, it was meant purely as an example of similarity, not a point of discussion or debate. > And you would see from which branch the commits came from: > Merge branch 'rlaager-foo' > https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 You will see this in monotone too, even without the branch certs, because of the changelog cert: http://developer.pidgin.im/viewmtn/revision/info/ebb9c5ce48a0ce5b73b9daf7a31c8178bf36fff3 > Sure, I haven't plotted the votes closely, but from what I recall most > of the votes where git/hg (slightly favoring one or the other), or > don't care. I don't recall anyone saying definitely no to git. Currently the votes give hg a 4 or 5 vote lead over git (I'd need to go back and recount to be sure, but hg is definitely leading). I don't expect any further votes to be cast at this point. I now consider this topic closed. John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From felipe.contreras@gmail.com Thu Jan 20 23:30:59 2011 From: felipe.contreras at gmail.com (Felipe Contreras) Date: Fri, 21 Jan 2011 06:30:59 +0200 Subject: Mercurial vs Git In-Reply-To: <4D38EFFE.7050704@rekkanoryo.org> References: <4D37B277.5050202@rekkanoryo.org> <4D38EFFE.7050704@rekkanoryo.org> Message-ID: Status: O Content-Length: 7297 Lines: 145 On Fri, Jan 21, 2011 at 4:31 AM, John Bailey wrote: > On 01/20/2011 05:35 AM, Felipe Contreras wrote: >> Why? How exactly would a floating reference affect your project negatively? > > It doesn't affect the project negatively, but it makes a specific scenario I've > run into before inconvenient for me. > > Regardless of how git, hg, mtn, or any other random SCM handles branches, one > simple fact does not change. ?I did *not* work on "master" or "default" or > whatever branch name when I was working on, say, a yahoo17 branch. ?Yes, the net > effect after a merge is that the *sum* of the branch is on "default", but the > individual revisions were *not* when they were created. > > This is an important distinction to me, because now I can prove to > $random_annoying_user that "bug X never existed on default because I both > introduced and fixed it on yahoo17 before it was merged." ?If I have to track > down the commit message of the merge, then walk the graph backward and guess > what branch revisions ABC and XYZ are on based solely on the appearance of the > graph, this becomes more of a pain than I'm willing to tolerate. ?Even if the > tool can figure this out for me, I still consider it a deficiency in the design. There's no "appearance", the graph is the graph, in mtn, mercurial, or git. And this graph has all the information you need. You have the point where it was introduced, the point where it was fixed, and the point when the branch was merged. Git has powerful commands that let's you find out exactly what you need. So, the mercurial model is better for you based on a personal feeling, there's nothing fundamentally wrong that prevents you from doing something, or that causes something bad. > Now I'm sure you'll make some argument about "it's your branch; you'll have the > ref to the head of the branch if you didn't delete it", but that argument > completely falls apart if I'm proving this for a branch I never worked on and > never explicitly pulled that ended up on default/master/whatever. ?It also falls > apart if I work from three different working copies on three different machines > without pushing/pulling changes among them, which I've done on more than one > occasion--I could be on a machine that doesn't have this all-important floating ref. No. Who cares whether or not you still have that pointer? You know which commit introduced it, and you know which commit fixed it, and you can get the branch merge point of both easily with git. That's all you need. > The bottom line is that in my opinion the git model of allowing the removal of > the branch ref and thus "collapsing" the "branch" into whatever it was merged > into leads to an inaccurate view of the history that I'm not happy about. ?Yes, > it's obvious from this statement that I don't follow the development model git > users do. ?It's pointless debating this any further (and in fact, further > messages on this topic *will* be ignored), because you're not going to convince > me that I'm wrong anymore than I'm going to be able to convince you that you're > wrong. ?I have far more important things to spend my time and energy on. A branch is a separate line of development. The base of the branch is the point where two commits have the same parent, and the branch can be merged to other branches. This "merge" as the English language defines it means to "absorb", "join", "combine", "become one", "immerse"; it doesn't matter how you look at it, merging 'foo' into 'master' means that 'foo' is now part of master. The Git model follows the mental model of "branch". What you want to define as a branch is actually not. What you want is something that says "this was here". That's not a branch, that something different, a "per-commit tag" perhaps, or a "commit label", or a "branch stamp". While this might be useful in certain limited scenarios, in the vast majority of situations, it's not. And whatever you can achieve with these 'stamps', exactly the same can be achieved without them, with a little bit of more work, which fortunately doesn't have to be done very often. Anyway, this is not me convincing you, and you convincing me, this is presenting arguments to a community which is trying to decide which DSCM to use. This decision obviously has many implications, and you can't just switch to another one next week if you realize you made a bad decision. Therefore the need to consider the decision carefully, and IMO something that would probably affect years of development is worth spending a bit of time discussing. So sad that you don't think so. >> And that demonstrates one of the many design inconsistencies about this model. >> >> ?1) commits can be part of no branch, even though they are parents of >> a commit in the main branch > >> The only thing that prevents those inconsistencies is the front-end >> app (does it?). With the git model, those things are impossible. > > If you want it to be impossible in monotone, you can force it to be impossible > by leveraging the lua extensibility in .monotonerc. ?Simply walk the graph and > manually "collapse" it into the target branch by issuing branch certs that force > those revisions onto the appropriate branch. ?The lack of a branch certificate > is not an inconsistency--it's simply saying "this revision came from outside our > normal world view." ?That said, it was meant purely as an example of similarity, > not a point of discussion or debate. Personally, that doesn't make sense to me. Every commit came from somewhere, and every commit that shows in the log of a branch, is part of that branch. >> And you would see from which branch the commits came from: >> Merge branch 'rlaager-foo' >> https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1 > > You will see this in monotone too, even without the branch certs, because of the > changelog cert: > http://developer.pidgin.im/viewmtn/revision/info/ebb9c5ce48a0ce5b73b9daf7a31c8178bf36fff3 That's irrelevant. What is relevant is that the branch name is not lost in Git. That is the context of the comment. >> Sure, I haven't plotted the votes closely, but from what I recall most >> of the votes where git/hg (slightly favoring one or the other), or >> don't care. I don't recall anyone saying definitely no to git. > > Currently the votes give hg a 4 or 5 vote lead over git (I'd need to go back and > recount to be sure, but hg is definitely leading). ?I don't expect any further > votes to be cast at this point. > > I now consider this topic closed. Advantages of Git: 1) more popular 2) more powerful handling of branches (distributed) 3) useful tools for pidgin migration (graft points) 4) more efficient 5) less space (108M the whole pidgin repo) Advantages of hg: 1) Adium/InstantBird use it (not that big of an advantage if hg clones are offered) 2) John likes the branch model Also, the mtn->git conversion takes 30m, while mtn->hg takes about 30h. So John is out. Hopefully other people would agree that up to this point, a careful evaluation of the alternatives hasn't been done yet (nobody has even put a list of pros and cons), and it is desirable to do so before committing on such big change. Cheers. -- Felipe Contreras From rekkanoryo@rekkanoryo.org Fri Jan 21 23:02:19 2011 From: rekkanoryo at rekkanoryo.org (John Bailey) Date: Fri, 21 Jan 2011 23:02:19 -0500 Subject: Time to Leave Monotone Behind? In-Reply-To: References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> Message-ID: <4D3A56CB.7050609@rekkanoryo.org> Status: O Content-Length: 1032 Lines: 33 On 01/19/2011 03:30 PM, Elliott Sales de Andrade wrote: > I'll +1 on hg also. > Though I'm not really soured on mtn, I understand the downsides WRT > downstream and casual contributors, so I don't mind if we decide to > move away from it. This seems like an excellent point at which to summarize again: Total votes in favor of hg: 9 * Developers: 6 * CPW's: 1 * Downstream Projects: 2 Total votes in favor of git: 3 * Developers: 3 Do any other developers/CPWs want to weigh in here, or should we consider the matter closed and declare hg the winner? Once we're clear on which tool we're going to switch to, we can hash out the specifics of the conversion (timeline, why I chose to convert in the way I did when faster methods are available, etc). John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From romain@peerfuse.org Sat Jan 22 03:55:30 2011 From: romain at peerfuse.org (Romain Bignon) Date: Sat, 22 Jan 2011 09:55:30 +0100 Subject: Time to Leave Monotone Behind? In-Reply-To: <4D3A56CB.7050609@rekkanoryo.org> References: <20110115183209.GC6934@rekkanoryo.org> <4D368FE5.50503@rekkanoryo.org> <4D3A56CB.7050609@rekkanoryo.org> Message-ID: <20110122085530.GA20342@symlink.me> Status: O Content-Length: 796 Lines: 24 On 21/Jan - 23:02, John Bailey wrote: > Do any other developers/CPWs want to weigh in here, or should we consider the > matter closed and declare hg the winner? In paste I wanted several times to send patches to Pidgin (on libpurple part) to fix minor bugs, and I was discouraged by the complexity of monotony. I'm not a developer, but a potentially contributor, as I'm the author of minbif[1], a libpurple frontend. So I don't know if my vote will be taken into account. For my part, I would vote for git. Romain [1] http://minbif.im -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: