Moving Away From CVS: A Vote
Max Kanat-Alexander
actually do it. We've been on CVS for too long--we may be the only
remaining major Mozilla project still using CVS for primary development.
We're certainly the only major open source project that I know of and
interact with regularly that still uses CVS.
The only reason that we haven't moved yet is that we have a conflict:
* Bzr is known by the Bugzilla developers and is technically superior
to Hg in almost every way except scalability (and even that may be fixed
as of bzr 1.16).
* Hg is supported by the Mozilla Corporation, has an extensive
infrastructure at Mozilla, and is already in use by Mozilla localizers.
If you doubt that bzr is technically superior, here are a few points:
* Compare the standard web interface to Hg (hgweb:
http://hg.mozilla.org/ ) to the standard web interface for bzr
(loggerhead: http://bzr.bugzilla.org/ ).
* bzr has a *major* release nearly every month. (See the release notes:
http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html )
Mercurial's major releases are roughly 3 to 4 months apart (and there
were 9 months from 1.0 to 1.1).
* bzr tracks directory renames as well as file renames, meaning that it
doesn't show hundreds of files being renamed if you rename a
directory--it only shows the directory name changing. (This also means
that bzr can show the existence of empty directories in its changeset
history, and Mercurial cannot.)
* The commands used in bzr for a CVS-like workflow are *identical* to
the commands used in CVS, drastically lessening the learning curve for
users migrating from CVS.
However, Hg is supported by the Mozilla Corporation and they already
have extensive infrastructure around it. Also, as Cedric has pointed out
in the past, localizers are already using Hg.
To resolve the conflict, I am ***TAKING A VOTE***:
* Respond to this email either publicly (if you want to make an
argument) or privately with your preference stated AT THE VERY TOP OF
THE EMAIL. Anybody who is currently contributing to the Bugzilla Project
or interacting with our CVS is eligible to vote. (If you are not a
current contributor, please state your interest when voting.)
I will count all public and private votes, and we will move to
whichever VCS receives a simple majority (51%) of the received votes.
HOWEVER, if there is a clear consensus (75% or greater) among the
reviewers (and a significant number of reviewers vote--more than just 3
or 4), then there is a possibility we will just go with the reviewer
consensus, though the non-reviewer votes will also be taken into account.
If you have any questions about the voting or about either VCS, feel
free to respond here publicly and I'd be happy to clarify.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps...@lists.mozilla.org>
Max Kanat-Alexander
more limited basic feature set and slightly awkward UI of Hg and hgweb,
after using bzr and loggerhead for a long time, and because we are
already using bzr for Bugzilla QA.
Marc Schumann
- I use bzr for bz de l10n
- bzr works really well on Win
- I'm told Hg is a pain on Win
- I've never used Hg
Regards
Marc
Frédéric Buclin
> The only reason that we haven't moved yet is that we have a conflict:
You forgot quite a few other reasons:
* PatchReader (even with my patch applied) cannot display patches with
context=file.
* Neither Bonsai nor Tinderbox support bzr, AFAIK.
As a core developer, I cannot write nor review code without these tools.
LpSolit
Max Kanat-Alexander
> * Neither Bonsai nor Tinderbox support bzr, AFAIK.
Bonsai doesn't need bzr support, because we have loggerhead, which does
pretty much everything thing that Bonsai does.
We can make the tinderbox clients support bzr really easily, and I
think that's all that's really critical for us to move to bzr.
As far as the PatchReader stuff goes, we don't have that for Hg either,
so I don't think we should hold up on that.
In any case, do you have a vote for Hg vs. bzr?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Frédéric Buclin
> Bonsai doesn't need bzr support, because we have loggerhead, which
> does pretty much everything thing that Bonsai does.
Except it doesn't display the bug ID + summary when hovering a commit
ID. This would need to be hacked to do that.
> As far as the PatchReader stuff goes, we don't have that for Hg
> either, so I don't think we should hold up on that.
We definitely should. I *always* do reviews in context=file mode. Not
being able to do this anymore is a showstopper for me. I don't care we
don't have that for Hg either; we do have it for CVS, and that's all
which is important to me.
> In any case, do you have a vote for Hg vs. bzr?
I have one, yes, but my issues mentioned above make my vote irrelevant
for now.
LpSolit
Guy Pyrzak
equiv for either Hg or bzr?
Hg vs Bzr is kinda hard for me since I've never used Hg and I've been using
BZR for my "real" job more or less every day... so I'm kinda bias.
-Guy
2009/9/4 Frédéric Buclin <lps...@gmail.com>
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.p...@gmail.com>
>
Max Kanat-Alexander
> Le 05. 09. 09 00:44, Max Kanat-Alexander a écrit :
> being able to do this anymore is a showstopper for me. I don't care we
> don't have that for Hg either; we do have it for CVS, and that's all
> which is important to me.
Okay. Well, let's assume that you resolve this (since you are totally
capable of doing so, being the module owner) before we move. What would
your vote be?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps...@lists.mozilla.org>
Frédéric Buclin
> What would your vote be?
bzr. I already use it for Selenium, and used it with ES.
LpSolit
Cédric Corazza
AFAIK, and I guess the current localizers are tech savvy enough to
switch from VCS tool. Thus, the rationale to stick with Mercurial seems
to be weaker in that context.
Though it will be yet another tool to play with, the mentioned benefits
seem this switch is worthwhile.
So, I would vote to switch to Bazaar.
I would like to have some other localizers' opinion though.
David Miller
local hacks, and to me the command set just seems more friendly than Hg.
The scalability/performance issues that Mozilla ran into don't really
affect us because our codebase isn't as huge as theirs.
If we end up going with this, I'll see to it that we get "real" support
for it on Mozilla's infrastructure (rather than the "nothing more than a
bare repo" that we have for bmo currently, that shares a server with one
of the staging boxes).
Max Kanat-Alexander wrote on 9/4/09 6:28 PM:
> Okay, we've had this discussion before, but this time, we have to
> actually do it. We've been on CVS for too long--we may be the only
> remaining major Mozilla project still using CVS for primary development.
> We're certainly the only major open source project that I know of and
> interact with regularly that still uses CVS.
>
> The only reason that we haven't moved yet is that we have a conflict:
>
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
Bill Barry
> Anybody who is currently contributing to the Bugzilla Project or
> interacting with our CVS is eligible to vote. (If you are not a
> current contributor, please state your interest when voting.)
Not a contributor currently so my vote doesn't really count but I would
vote Mercurial.
There is significant fear that bazaar will break compatibility in
upgrades (it has already done so before). As someone who only rarely
updates Bugzilla and even far more rarely updates underlying system
infrastructure (at that level bureaucracy is simply to much in the way)
what guarantees do I have that "bzr up" will continue to work a year
from now the next time I update Bugzilla?
Any other reasons I have for wanting Mercurial are not things this
community should care about (I have infrastructure and tooling support
built up for Mercurial but not Bzr; I am active in the Mercurial dev
community; etc.).
Your FUD about Bzr being superior is BS:
* Comparing the interface is merely subjective. I very much like the Hg
interface better for one.
* Bzr has a new release every month because it finds major deficiencies
every month. It also doesn't have minor releases and every single
release has had breaking changes. In a corporate environment there is no
reasonable suggestion for bzr to remain in any state of stability if you
are interacting with repositories in external environments.
* While this is true, it is also pointless. I have yet to see any reason
why you might need to track empty directories which couldn't be
accomplished by tracking an empty file in a directory.
* The mercurial commands are not significantly different than CVS or SVN.
As far as superiority: last I checked over 90% of the commits to Bzr
were from 2 or 3 people employed by Canonical. There literally was not a
developer community.
Regardless, all I really want is for our benevolent dictator for the
time being to decide and make the move (and to see a testopia repository
that keeps up to date with the changes as they happen).
Max Kanat-Alexander
> There is significant fear that bazaar will break compatibility in
> upgrades (it has already done so before).
The fear is unfounded. Bazaar has never actually *broken compatibility*
in its upgrades--at least not that I recall since 1.0. However, if
administrators of bzr servers choose to convert their repositories to a
format that older versions of Bazaar don't support, then it's true that
older versions of Bazaar can no longer access those repositories.
There would probably be a decision made when we switch to bzr what
repository format we were going to use, and then we'd stick with it
until such a time as all reasonably available versions of bzr supported
a newer repository format (most likely several years). Also, it's
looking like the 2a format may indeed be the last word in formats--we'll
see. At the least, the packs format is good enough for what we do with
Bugzilla, so we may not ever have to change.
> * Bzr has a new release every month because it finds major deficiencies
> every month.
Not really. Read the release notes and see.
> It also doesn't have minor releases
Not true, it's had some minor releases. See the release notes. There
was a 1.6.1, as an example.
> * The mercurial commands are not significantly different than CVS or SVN.
Except that last time I checked, Mercurial lacks built-in support for
bound branches--the fundamental CVS/SVN workflow (that you commit back
to the branch you checked out from with a "commit" command).
> As far as superiority: last I checked over 90% of the commits to Bzr
> were from 2 or 3 people employed by Canonical. There literally was not a
> developer community.
Here's the current list of top contributors to bzr:
https://launchpad.net/bazaar/+topcontributors
(Looking at the "Bazaar Branches" section will limit it to just code
contributors.)
> see a testopia repository
> that keeps up to date with the changes as they happen).
That would depend more upon somebody committing development resources
to Testopia than a VCS switch, although switching to a DVCS would
certainly have some advantages. I agree it would be nice, though. :-)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Bill Barry
> On 09/05/2009 03:43 PM, Bill Barry wrote:
>> There is significant fear that bazaar will break compatibility in
>> upgrades (it has already done so before).
>
> The fear is unfounded. Bazaar has never actually *broken
> compatibility* in its upgrades--at least not that I recall since 1.0.
> However, if administrators of bzr servers choose to convert their
> repositories to a format that older versions of Bazaar don't support,
> then it's true that older versions of Bazaar can no longer access
> those repositories.
server was working because we couldn't push to it. A new version came
out about a week after we started evaluating bazaar and we decided to
upgrade and found that we couldn't push to it. I think it was 1.13 or
something like that. We gave up pretty quickly after that.
>
> There would probably be a decision made when we switch to bzr what
> repository format we were going to use, and then we'd stick with it
> until such a time as all reasonably available versions of bzr
> supported a newer repository format (most likely several years). Also,
> it's looking like the 2a format may indeed be the last word in
> formats--we'll see. At the least, the packs format is good enough for
> what we do with Bugzilla, so we may not ever have to change.
>
>> * Bzr has a new release every month because it finds major deficiencies
>> every month.
>
> Not really. Read the release notes and see.
seems to fix at least a dozen bugs. How exactly does there happen to be
a new bug fixed every other day on average? How do that many bugs get in
the code in the first place? The only ways I can think of are either
poor coding or hastily done work (which then gets fixed in some
subsequent release; as paid developers on a project from a company with
an agenda).
Wasn't it you that wrote the post about sucking less every release?
>
> > It also doesn't have minor releases
>
> Not true, it's had some minor releases. See the release notes.
> There was a 1.6.1, as an example.
I am sorry, I was wrong there.
>
>> * The mercurial commands are not significantly different than CVS or
>> SVN.
>
> Except that last time I checked, Mercurial lacks built-in support
> for bound branches--the fundamental CVS/SVN workflow (that you commit
> back to the branch you checked out from with a "commit" command).
No it doesn't have bound branches; I'll give you that too. I don't think
it would be that difficult to write as an extension. I did write an
auto-push extension which would function just like bound mode in all
cases except for when pushing would first require a merge, but the
repository shouldn't be deciding when to merge. That should be a user
decision (in Mercurial you may instead want to rebase for instance).
My bound mode extension can be found here:
https://bitbucket.org/Bill_Barry/boundmode/
In bound mode the centralized workflow would be:
setup:
1. hg clone path
2. hg bind path
daily use:
3. hg pull --update
4. do work
5. hg ci
if ci fails to push (push may be aborted if there already exists a head
on the central which you don't have)
3. hg pull --update
4. do work
5. hg ci (fails to push)
6. hg pull --rebase
7. hg push
or
6. hg pull
7. hg merge
8. hg ci
or
6. hg fetch
7. hg push
or
6. hg push --force
or any number of other options. The point being that Mercurial shouldn't
do any magic like automatic merges (which is why fetch is in an
extension and not in the core by default). But there isn't anything that
says I couldn't write an extension that does this just like Bazaar does
(and in fact it would be a fairly simple extension come to think of it;
simply a push/pull/merge/commit loop until it succeeds).
>
>> As far as superiority: last I checked over 90% of the commits to Bzr
>> were from 2 or 3 people employed by Canonical. There literally was not a
>> developer community.
>
> Here's the current list of top contributors to bzr:
>
> https://launchpad.net/bazaar/+topcontributors
>
> (Looking at the "Bazaar Branches" section will limit it to just
> code contributors.)
That has changed considerably since we last looked at it over in the
Mercurial list:
http://www.selenic.com/pipermail/mercurial/2009-January/023261.html
>
>> see a testopia repository
>> that keeps up to date with the changes as they happen).
>
> That would depend more upon somebody committing development
> resources to Testopia than a VCS switch, although switching to a DVCS
> would certainly have some advantages. I agree it would be nice,
> though. :-)
It will be much easier to maintain a fork than it currently is to
maintain a single giant patch. I pity what Greg has to go through each
time he attempts to upgrade Testopia. That is a lot of work (which
wouldn't be nearly so difficult if it was easier to keep up with the
changes). His latest news was a bit unsettling as far as the future for
Testopia goes.
Max Kanat-Alexander
> I seem to recall some dirstate problem that we had to change how our
> server was working because we couldn't push to it. A new version came
> out about a week after we started evaluating bazaar and we decided to
> upgrade and found that we couldn't push to it. I think it was 1.13 or
> something like that. We gave up pretty quickly after that.
Hmm. It's possible there was a problem with dirstate that I never ran
into. At this point most repos are in the packs format (same as git
uses) and it seems to be working totally fine.
> Every release (and there has been almost 1 a month for the past 2 years)
> seems to fix at least a dozen bugs. How exactly does there happen to be
> a new bug fixed every other day on average?
I'd say that probably a lot of what's showing up there is just issues
found in Release Candidates. Not sure, though. I haven't encountered a
serious issue in bzr in a while.
> Wasn't it you that wrote the post about sucking less every release?
Hahaha, it was. :-)
> No it doesn't have bound branches; I'll give you that too. I don't think
> it would be that difficult to write as an extension. [snip]
Fair enough. I think bound branches is how we'd recommend users check
out Bugzilla code, though, so that they could do "bzr up" and it would
"just work" pretty nicely.
As a result of having bound branches, bzr also has "lightweight
checkouts", which are just a copy of the working tree without the entire
history, and a pointer back to the main repo for operations that require
the history. Of course, I've never used lightweight checkouts, and I
don't know anybody who does. :-)
> My bound mode extension can be found here:
> https://bitbucket.org/Bill_Barry/boundmode/
Cool. I will look into that if we go with Hg (though the way the voting
is going bzr seems pretty likely).
> It will be much easier to maintain a fork than it currently is to
> maintain a single giant patch. I pity what Greg has to go through each
> time he attempts to upgrade Testopia. That is a lot of work (which
> wouldn't be nearly so difficult if it was easier to keep up with the
> changes).
Yeah, I wouldn't want to maintain Testopia without bzr, myself, if I
were a maintainer. Of course, I think the "Testopia For Bugzilla 3.4"
may not involve a patch to Bugzilla at all. We'll see. :-)
> His latest news was a bit unsettling as far as the future for
> Testopia goes.
Yeah, agreed, but it's possible we'll see some community member come
and pick it up.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Charlie Powell
That said however, I am neither an active contributor nor a user of either bzr or hg, so this vote can count for half :p
Hahaha, it was. :-)
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=pow...@powelltechs.com>
Gervase Markham
> Although I don't have much experience with either Hg or Bzr, it
> appears to me that bzr has more support backing its development and
> use; Hg just has Mozilla corp.
I'm not sure what you mean by that. Mercurial (Hg) is not a Mozilla
Project project, but an independent project, used by many free and open
source projects, as listed at the bottom of this page:
http://en.wikipedia.org/wiki/Mercurial_%28software%29
Gerv
Gervase Markham
On 04/09/09 23:28, Max Kanat-Alexander wrote:
> If you doubt that bzr is technically superior, here are a few points:
>
> * Compare the standard web interface to Hg (hgweb:
> http://hg.mozilla.org/ ) to the standard web interface for bzr
> (loggerhead: http://bzr.bugzilla.org/ ).
Here's a test for function I've needed from the 3 major Mozilla SCMs
recently: can it give me an XML or RSS feed of all changes in the entire
repository (or, perhaps, a separate feed for each branch) from a
particular date, say, six months ago?
> * bzr has a *major* release nearly every month. (See the release notes:
> http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html )
> Mercurial's major releases are roughly 3 to 4 months apart (and there
> were 9 months from 1.0 to 1.1).
I really don't think release frequency is a good metric of software quality.
> However, Hg is supported by the Mozilla Corporation and they already
> have extensive infrastructure around it.
I personally use an abstraction library (Patch Maker -
http://www.gerv.net/software/patch-maker/) to work with multiple SCMs,
so in one sense it doesn't matter too much. And I've certainly found Hg
difficult to use. But my one big concern would be the level of support
we would get from Mozilla IT if we asked them to support Yet Another SCM
system. If justdave is telling us he can guarantee that Mozilla IT will
properly support bzr, then I'll abstain. Otherwise, I vote for Hg.
Gerv
Anjali Sharma
I installed Bugzilla on windows. Now i want to customize the existing
template of it according to my requirement. Please let me know how can i do
it asap.
Thanks
Anjali Sharma
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=sharmaa...@gmail.com>
>
Frédéric Buclin
> I installed Bugzilla on windows. Now i want to customize the existing
> template of it according to my requirement. Please let me know how can i do
> it asap.
You are completely out of topic, and this is not the right place to ask
for help, see http://www.bugzilla.org/support/.
LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps...@lists.mozilla.org>
Max Kanat-Alexander
> Here's a test for function I've needed from the 3 major Mozilla SCMs
> recently: can it give me an XML or RSS feed of all changes in the entire
> repository (or, perhaps, a separate feed for each branch) from a
> particular date, say, six months ago?
Yeah, I'm pretty sure you can get Atom limited by date. It's not
something that's directly in the UI, but you can just add a few URL
parameters that are probably documented somewhere that I could look up
for you some time, if you'd like. (Or you could ask in #bzr on FreeNode
if the loggerhead devs are around when you ask--beuno is the main one, I
think.)
> I personally use an abstraction library (Patch Maker -
> http://www.gerv.net/software/patch-maker/) to work with multiple SCMs,
> so in one sense it doesn't matter too much.
I note you added bzr support recently--perhaps basing it on the
bzr-loom plugin would make things easier in that department.
Gervase Markham
> I note you added bzr support recently--perhaps basing it on the bzr-loom
> plugin would make things easier in that department.
The bzr support is almost entirely untested; I use no bzr repositories
apart from the one containing b.m.o., and I haven't used that for some time.
Gerv
Gregary Hendricks
Kanat-Alexander <mka...@bugzilla.org> wrote:
> Okay, we've had this discussion before, but this time, we have to
> actually do it. We've been on CVS for too long--we may be the only
> remaining major Mozilla project still using CVS for primary development.
> We're certainly the only major open source project that I know of and
> interact with regularly that still uses CVS.
>
I guess I will weigh in.
I personally have no experience with either Hg or bzr and much prefer svn to anything else I have used. My biggest concerns are having IDE support, especially Eclipse since that is my preferred development environment. A quick google search shows that there are clients for both.
Either way, I am going to have to learn a new VCS, but I trust Max's judgement and I like the fact that a company like Canonical is behind it. I know something of the complexity of managing a distribution and if they can apply that understanding to source control, it must have been pretty well thought out.
As for Testopia, I will switch to use whatever Bugzilla goes with as I am rather tied to that platform as it is anyway.
Greg
Gregary Hendricks
<after....@gmail.com> wrote:
> Max Kanat-Alexander wrote:
> > On 09/05/2009 03:43 PM, Bill Barry wrote:
<snip>
> >> see a testopia repository
> >> that keeps up to date with the changes as they happen).
> >
> > That would depend more upon somebody committing development
> > resources to Testopia than a VCS switch, although switching to a DVCS
> > would certainly have some advantages. I agree it would be nice,
> > though. :-)
> It will be much easier to maintain a fork than it currently is to
> maintain a single giant patch. I pity what Greg has to go through each
> time he attempts to upgrade Testopia. That is a lot of work (which
> wouldn't be nearly so difficult if it was easier to keep up with the
> changes). His latest news was a bit unsettling as far as the future for
> Testopia goes.
Thanks for the thought. :)
I will admit, keeping abreast of what is going on in Bugzilla via CVS even with tools like Bonsai could keep me occupied full time. What I usually end up doing is using a 3 way diff tool like kdiff3 to view the changes to the entire Bugzilla release at once. I then keep a subversion branch that I use to create the patches that I apply to the CVS repository before checking in each change. It certainly isn't ideal and I hope that whatever we come up with is a better solution.
And Testopia isn't dead... just hobbled a bit. ;)
Vitaly Fedrushkov
1. TortoiseHg is still inferior to TortoiseBzr. TortoiseBzr in turn sucks when
compared to TortoiseSVN (for instance, it depends on ugly daemon), but hey,
Subversion is so old and mature...
2. TortoiseHg is still broken in handling of cyrillic file names. Probably
other UTF-8 languages too.
I like Linux and prefer Linux. I just cannot afford to leave Windows.
l10n standpoint:
1. Transifex supports both bzr and hg. Had UTF-8 problems at hg backend,
current status unknown.
2. Pootle and Translate Toolkit support bzr. Hg is being actively worked on,
due to Mozilla's move.
3. Launchpad Rosetta implies bzr. CVS, Subversion and git are import only, with
Mercurial 'coming soon'...
None the less: if not Bazaar, I will appreciate move to Mercurial: at least
because we are _moving_ out of CVS!
Regards,
Vitaly.