https://bugzilla.mozilla.org/show_bug.cgi?id=470570
The bug itself contains the reasoning for why we'd pick bzr,
and you should read the whole Description of that bug before making any
comments here.
However, this is the place to talk about the proposal, since
I'm sure that somebody somewhere will have opinions about it, and
I wanted to direct them here instead of in the bug, where we
should keep things to discussing the implementation of whatever we
do. :-)
"CVS is great and we shouldn't move away from it," is an
argument that we are probably all guaranteed to ignore. :-)
However, I'm open to arguments that we should move to some
*other* VCS, or talking about how the move to bzr should go, or
whatever. Honestly, I really like bzr, personally, and a lot of the
Bugzilla developers have experience with it, so convincing us to go
elsewhere could be difficult, but I'm not totally close-minded on the
issue personally, and I'm sure that the rest of the team isn't either.
Anyhow, anybody who wants to chime in (even to say "Yeah, bzr
sounds great, +1!") is welcome to do so, here. :-)
-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>
MK> However, I'm open to arguments that we should move to some *other*
MK> VCS, or talking about how the move to bzr should go, or whatever.
In my opinion bzr is ridiculously slow. But as long as it is easy to
have a hg or git mirror, it really does not matter at all.
--
Have you used it lately? It's been perfectly fine for me, for
quite some time now--since 1.0, really, which was 10 major releases ago.
Try some of the latest releases.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Jochen
Oh, that's a good question. I suspect that a lot of us don't
use any of the major IDE's, though. They tend not to have very good
support for Perl or dynamic languages in general. When I do use an IDE,
I use Komodo (which is what I suspect many dynamic-language
programmers use when they use an IDE), and Komodo 5 does have Bazaar
support.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander wrote:
> So, I've filed a bug for moving away from CVS, and probably to
> bzr:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=470570
-
MK> Have you used it lately?
I do it every year after I hear "have you tried it lately?" again :)
MK> It's been perfectly fine for me, for quite some time now--since
MK> 1.0, really, which was 10 major releases ago. Try some of the
MK> latest releases.
1.10 is better than 1.5 I tested several days ago. Still 10min/2min for
remote/local cloning of whole Python repo, but it is tolerable (it was
25min/6min for 1.5). Painful (hg: 3min/13sec, git: 4.5min/10sec), but
tolerable.
Test code:
http://www.bitbucket.org/ArneBab/hg-vs-bzr-speedtest-unscientific/
--
Yeah. Also, the python repo has 40,000 revisions, and we have
only about 7000. You can try the current bzr mirror of Bugzilla with:
bzr://bzr.everythingsolved.com/bugzilla/trunk
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
I would only have a regret as a localizer:
We currently have to deal with CVS (for 1.9.0 Gecko branch), HG (for
1.9.1 gecko branch), SVN for Mozilla Web files, and that would mean we
will have to deal now with a fourth VCS :-( .
Apart from the fact the dev team already dealt with bzr repos, are there
any other reasons to move to Bazaar?
Is Mercurial not an option, and if so why?
The multiplicity of tools is an obstacle for new locales to come.
Though this move is just about the Bugzilla Project, Bugzilla is part of
the Mozilla products.
I just wanted to state about this part of the move.
Cédric
http://www.versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
For Windows users: Tortoisebzr is included with distribution. But 1.10
binary not released yet.
How to emulate CVS sticky tags with Bazaar? Already lacking them in
Subversion.
Regards,
Vitaly.
CC> A localization point of view.
Something like http://transifex.org/ should help. However I'm not sure
is Transifex gettext-only, or can be set up to fetch different types of
to-be-translated files.
--
I think this point is not to be underestimated. Currently, the Mozilla
project uses (IMO) too many different VCSes. How it got that way is
history, and we are currently in the middle of a transition, but it
would be good to work towards having fewer. CVS will die slowly, and
perhaps one day the SVN repo will move to Hg too. Adding a fourth VCS to
the mix certainly doesn't help this goal.
Justdave: does the IT team have any views on VCS consolidation, or is
the official line that "we'll support whatever people want to use"?
Gerv
bzr tag -r1234 some_tag
bzr co -rtag:some_tag some/branch
Works very nicely. :-)
http://bazaar-vcs.org/BzrVsHg is a fairly good explanation of
some of the advantages of Bzr over Hg.
> Is Mercurial not an option, and if so why?
It's an option, it's just not the preferred option at the
moment, though we could possibly be convinced otherwise. I think bzr
has better architecture, is simpler, and has better prospects for
future improvement than Mercurial does (particularly given how quickly
and often bzr releases).
> The multiplicity of tools is an obstacle for new locales to come.
> Though this move is just about the Bugzilla Project, Bugzilla is part
> of the Mozilla products.
> I just wanted to state about this part of the move.
Yeah, I understand, and I appreciate you bringing up the point.
I think that lots of people are experiencing this nowadays--for so
long, CVS was the de-facto standard, and then after that, there was only
SVN to replace it. But then suddenly there were several DVCSes, all at
once, to replace SVN & CVS, and none of them have really come out as a
clear standard. My understanding is that even with hg.mozilla.org, it's
not guaranteed that Mozilla is going to stay with it forever, only for
this Core development cycle.
CVS is great....
> whatever. Honestly, I really like bzr, personally, and a lot of the
> Bugzilla developers have experience with it
Who are they, besides you and justdave?
There's few utilities I'd like to still work without much complication
so I can still review and write patches for the Bugzilla Project. As
long these are addressed one way or another, I can be convinced to move
to bzr or some other CVS.
These are:
1) "cvs update" to bring my landfill test instances up to date (and
show all conflicted and modified files),
2) "cvs update -C" to blow away all modifications on an instance,
3) "cvs diff" to make reviewable patches and see local changes,
4) "bzpatch" to install patches from BMO,
5) Landfill Patch Database Administration website and scripts still
functional so new test instances can be easily created for new branches and
6) Bonsai and MXR utilities to view sources and their changes.
[7) Some other utility as I have a feeling that I'm forgetting something
important.]
As I currenly understand, bzr supports same command sets than cvs so
point 1 through 3 should work. And I'm sure you or someone else can fix
points 4 through 5 on landfill. That leaves point 6 that might or might
not be fixed with loggerhead (but this is not the most important point
for me anyway). Does MXR already support bzr?
> "CVS is great and we shouldn't move away from it," is an
> argument that we are probably all guaranteed to ignore. :-)
CVS is working just fine for me.
> However, I'm open to arguments that we should move to some
> *other* VCS, or talking about how the move to bzr should go, or
I do hope bzr's loggerhead that is supposed to replace Bonsai is much
more functional than the hg thing Mozilla uses is. It's so cumbersome to
use it that I simply can't get anything done with it. :(
So if there's no better implemention of Bonsai for Mercurial then I'd
vote against choosing it.
--
"Anything is possible but probabilities vary."
"Whatever. Life goes on." -Dark Angel
Are you looking for the ability to search history easier? I'll agree
that hgweb doesn't do that very well (that single textbox does work and
I think it accepts python regexes to search through history). However,
since history is local, hg comes with a command called "hg grep" which
is rather useful in searching through history (tortoisehg provides a
datamine feature to access this functionality through a gui). Also
something to consider is the "hg bisect" command which allows you to
find when a change appeared first through a interactive search.
What else does bonsai do that is missing in Mercurial?
I think bzr has pretty much the same functionality here anyways. Btw, if
that isn't enough, you can always register a branch at bitbucket
(www.bitbucket.org) for hg or launchpad for bzr (https://launchpad.net/)
What I have been trying to get from hqweb is a list of all changes
committed after a certain nightly or released version of FF/TB. It would
ideally list a date, complete description, list of changed files and has
a link to get a full diff (changeset?) of changes.
I can't see no way to have from and to date filters and while hqweb has
three or four different list formats none of them give what I want in
simple and clear way. Not to mention paging through a list is way too
complicated.
For Bugzilla I use changelog and blame output of Bonsai to see history
of one file. Not to mention http://www.bugzilla.org/status/changes.html
is valuable information (this is also exactly what I miss for TB/FF).
--
"Anything is possible but probabilities vary."
"Whatever. Life goes on." -Dark Angel
-
Well, you and bbaetz, and anybody else who's ever done work for
Everything Solved. :-)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
bzr update
> 2) "cvs update -C" to blow away all modifications on an instance,
bzr update
bzr revert
> 3) "cvs diff" to make reviewable patches and see local changes,
bzr diff
> 4) "bzpatch" to install patches from BMO,
Easy enough to adapt, I'm rather fond of it too. Also, this
might work though I haven't tried:
bzr patch http://some.url/
> 5) Landfill Patch Database Administration website and scripts still
> functional so new test instances can be easily created for new
> branches
Ah, I'll add that to the bug, thanks. :-)
> 6) Bonsai
Loggerhead: http://bzr.bugzilla.org/
It also has some undocumented features, so if it's missing
something that you want, it's easy enough to ask the developers about
it (they hang out in #bzr on FreeNode).
> and MXR utilities to view sources and their changes.
MXR isn't tied to any particular VCS, as far as I know.
Wow, I don't consider myself as having experience with bzr. I spent my
time in #async when I had problems (and I had many :)).
Well, more than you have with Mercurial or Git, right? :-)
> I spent my time in #async when I had problems (and I had many :)).
Well, nowadays the workflow can be identical to CVS for most
people:
bzr checkout
bzr update
bzr diff
bzr commit
So I think things should be fairly easy for people.
I suspect you'd also appreciate the "bzr shelve" and "bzr
unshelve" commands (they're now integrated as of bzr 1.10) which allow
you to work on multiple patches using the same directory.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
I've used neither, in fact, I've only ever used CVS and SVN although I am
about to learn git for work, so if we could move to that it would help ;-)
Serious comment - why move to BZR instead of Mercurial, which (I think is
what) the other Mozilla projects appear to be moving to?
Surely having BZR is just 'another new thing to support' from that point of
view?
I'm sure I read somewhere in the discussion about it being a VM on some
server - being supported by Max. Surely moving to the same as the other
projects means that you have dedicated support etc. for that from the
Mozilla IT team rather than having to rely on one person... single points
of failure are bad and all that.
I'm not against moving, I just think it would be better to move to
something that's being used by other parts of the mozilla projects etc.
Although I do think this discussion should have been had BEFORE the bug was
open and the bug only opened once the discussion was completed...
Cheers,
Colin
--
Colin Ogilvie
bugz...@colinogilvie.co.uk
The question's been asked a few times in this thread.
http://bazaar-vcs.org/BzrVsHg is a fairly good explanation of some of
the advantages of Bzr over Hg. There are also other advantages not
listed there.
> I'm sure I read somewhere in the discussion about it being a VM on
> some server - being supported by Max.
Or possibly run by MoCo. I'd be OK with that. reed talked to me
about it today, it's a possibility.
VCS systems don't really require that much administration,
though, particularly for a project of our size.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
How many of those are actually relevant to the Bugzilla project though?
Also, what other VCSs have been discussed other than Bzr and why were
they discounted?
> Or possibly run by MoCo. I'd be OK with that. reed talked to me
> about it today, it's a possibility.
>
> VCS systems don't really require that much administration,
> though, particularly for a project of our size.
Nope, but if they go down or theres some sort of corruption etc. it's
best not to have a SPOF... the more extreme example is you get hit by a
bus or something, not that we'd want that to happen!
Colin
CO> Also, what other VCSs have been discussed other than Bzr and why
CO> were they discounted?
'cause Max loves bzr :)
CO> Nope, but if they go down or theres some sort of corruption
CO> etc. it's best not to have a SPOF... the more extreme example is
CO> you get hit by a bus or something, not that we'd want that to
CO> happen!
All DVCS have "built-in backup solution" called clone/branch/checkout :)
--
So we have a sudden security release, and the 'mater' repo goes dead,
and Max is nowhere to be seen - where do the people that use the VCS
method of keeping up to date get their update from?
Colin
Well, did you read them?
The workflow aspect is pretty relevant--it's nice that you
don't have to reeducate people, they can still use the exact same
workflow they had in CVS.
Loggerhead is nicer than Hgweb, in my experience.
We do move and rename directories, and the ability to merge
the inventory correctly is a good thing, in that case, particularly for
bound branches.
I personally think the plugin aspect is really useful, I use a
few plugins myself, and I really like the bzrtools plugins package in
particular.
> Also, what other VCSs have been discussed other than Bzr and why were
> they discounted?
We're basically discussing them now, this would be the
place. :-)
Mozilla narrowed down the discussion to bzr and hg way back
when (and I participated in the discussion) when they were picking a
DVCS to move to, and Hg was only picked because it could scale to the
level that Mozilla needs. I'm pretty sure that otherwise we would have
gone with bzr.
> Nope, but if they go down or theres some sort of corruption etc. it's
> best not to have a SPOF... the more extreme example is you get hit by
> a bus or something, not that we'd want that to happen!
Hahahaha, yeah. :-) And believe me, I don't really *want* to be
administering a VCS, and particularly not forever. I'm doing my best to
get *away* from sysadmin tasks for the Bugzilla Project. But I really
think that bzr is the best choice (I mean, I'm willing to be convinced
otherwise, but that's what I think right now), and I'm willing to take
on a bit of sysadmin work if it means that we can move to it.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
I barely did anything with bzr, but I don't have any hg experience either, so...
I don't necessarily mind moving away from CVS, and its not like we
have complicated needs, but can tinderbox hook in with bzr? We do rely
on m.org infrastructure, and it just seems like Yet Another VCS may
not be the way to go.
Bradley
Yeah, it should be fine. And also we're going to maintain a
bzr->cvs mirror, so the tinderbox tools can keep using that.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
I use Eclipse with EPIC for all my Perl development. I like its support for SVN and CVS which make patching, diffing, and checkins extremely simple. I also love how Mylin connects SVN with Bugzilla. I am all for moving away from CVS, but I wonder what the arguments against SVN are. I noticed it wasn't even mentioned in the list of "modern" VCSs.
Can anyone point to a good bzr plugin for Eclipse?
=+= May the Source be with you =+=
Greg
We want a DVCS. If you'd like to know the advantages of a DVCS
over a centralized VCS, there are lots of good resources on the
Internet, or you can ask me on IRC.
> Can anyone point to a good bzr plugin for Eclipse?
http://www.google.com/search?q=bzr+eclipse
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
while it is not "tied" to any particular VCS, it does to the extent
possible offer integration hooks with them.
If you load a mxr source page especially for files (but also in
certain cases for directories) you will get links in the top right
corner to various integration points.
bzr has proved to be the worst in supporting such links (I have a
draft change to support git, but I've investigated integrating with
loggerhead [including contacting their group on irc] and concluded it
is not practical at this point).
What functionality are you missing? If it's the access-by-path stuff that
you asked *me* about, that is available:
http://bzr.bugzilla.org/bugzilla/trunk/annotate/6363/Bugzilla/Constants.pm
Or replace "6363" with "head:" to get the latest revision.
Any other functionality you're missing that is actually important and
used by the Bugzilla Project, the loggerhead developers would be happy to
prioritize.
-Max
Another l10n-related issue: currently there are sites updating
Bugzilla and localized temptate sets directly from their version
control systems (CVS, Subversion). These systems have per-directory
version control containers (CVS, .svn, you know 'em all). In
contrast, Bazaar apparently uses single .bzr directory at root level.
Bad news: how does one overlay several bzr-controlled trees?
Good news: with introduction of bzr-style branches (and perhaps more
fine-grained access control) l10n projects may really coexist in the
same repository.
Regards,
Vitaly.
S> Bad news: how does one overlay several bzr-controlled trees?
Not a problem: just fetch from two repositories and merge them right on
the site (at least it works fine for git).
--
Yeah, we do that already on bmo, pulling both from the upstream repo and
our local one, and merging them as we go.
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
hi,
As a localization project (owner?), I think we'll have a separate
repository from the bugzilla.org for localization project itself.
B/c, we have some different policies (accounts, check-ins etc.) for
our project, and might be same for each localization project.
regards,
- --
Atsushi Shimono - shi...@mozilla.gr.jp
http://www.mozilla.gr.jp/~shimono/blog/
Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator
MDC Japan Project Leader, Bugzilla Localization Working Group Member
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
iQIcBAEBCgAGBQJJWzZFAAoJEAreYKYW9UUyn7EQALRqdmHvsSQsVO+hMVHiDyA4
4gvI+5eUGaKL8htYaJtYbEnhbNwYTqP5L3+4SxCDlvsbRxOvvTQ4rQawR9MjOJ3G
Rswl1RCIOFSZem5+iKUx/cwUwT503zNGO+l9pbn6TPI/7HcSAVwOM0NHlc0MvheB
DG7Ksy5Fgt6JJejxRfT3InCXSbcaNNXk2Yy5IMcmd/q5O4XZOU3sd3wxuOrPnaWM
W4CitpZb4+2lBNSrphpEDNFtWf+xOOvhRUxh4bM+HAzMWnp8gQTOBHfvaBhTY+mr
VGxpcSnFzvdW9ala9BaoES5v+GqHeYQS0/T1P2ZxnVZLG0IVb1yLx4xzWqyG4Lbw
MPxJoViztmw5lxFoi7IzLjTl8kAQsWNM2i6GoGq7WgHrz3Hx2C7e4tf6hbdyhlPk
+znHJ9kHCRDiEU8SpfUO4n5FrlHDzBt/uw8c0MxfiwIuRLn3aYOOFUPMtO7yjZXo
2j0Unbp9jnL7U2y9eX41Uilzi1AHR3fm0wTUsVzHE54kHLLKtRN62Yv7dGar2qBo
Q6msEULg9YBrrSapgPst7Sf3fYghNioBs/jmNlfbR+zU0wzzmLqABb29o2/iqLuL
jiEbsqmjYr4kI/xuldpoD4yDws3BMr1D/Z/SIUUMB/Xct0q75O6i9duP3djFSHL9
AzVYU6HGlkCw1YJuNvQk
=2yxY
-----END PGP SIGNATURE-----
And that's the beauty of a DVCS.
There is no concept of a "central" repository, except for convention of
people treating a particular one that way. You can merge back and forth
between different repositories whenever you feel like it. So you could
have a bzr repo for your localization, and we could merge the central
server from it periodically in order to give people the convenience of
being able to check it out from one spot. (just an example)
> Something like http://transifex.org/ should help. However I'm not sure
> is Transifex gettext-only, or can be set up to fetch different types of
> to-be-translated files.
Mozilla l10n team uses Narro:
https://l10n.mozilla.org/narro/
http://code.google.com/p/narro/
Regards,
Vitaly.
> I would only have a regret as a localizer:
> We currently have to deal with CVS (for 1.9.0 Gecko branch), HG (for
> 1.9.1 gecko branch), SVN for Mozilla Web files, and that would mean we
> will have to deal now with a fourth VCS :-( .
Update: bzr is recently implemented on SourceForge:
http://apps.sourceforge.net/trac/sourceforge/wiki/Bazaar so we can try to
abandon Subversion...
Vitaly,
This is not about hosting facilities, this is about dealing with many
versionning control systems. Currently, as a Mozilla contributor, I have
to deal with CVS, SVN and Hg (for code and websites). This is already a
barrier to most of new locales, especially the smaller ones with no or
few computer skills. Adding another one, only for Bugzilla, will not
bring more l10n contributors for Bugzilla.
Cédric
> This is not about hosting facilities, this is about dealing with many
> versionning control systems. Currently, as a Mozilla contributor, I have to
> deal with CVS, SVN and Hg (for code and websites). This is already a barrier
> to most of new locales, especially the smaller ones with no or few computer
> skills. Adding another one, only for Bugzilla, will not bring more l10n
> contributors for Bugzilla.
I'd support Cédric's view and vote for choosing either of the three
existing systems. Note that there are tools like git-svn, which allow
to use DVCS against an SVN server. I do not know about Hg, or Bzr, but
perhaps there are similar solutions?
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
> This is not about hosting facilities, this is about dealing with many
> versionning control systems. Currently, as a Mozilla contributor, I have to
> deal with CVS, SVN and Hg (for code and websites). This is already a barrier
> to most of new locales, especially the smaller ones with no or few computer
> skills. Adding another one, only for Bugzilla, will not bring more l10n
> contributors for Bugzilla.
I'd support Cédric's view and vote for choosing either of the three
existing systems. Note that there are tools like git-svn, which allow
to use DVCS against an SVN server. I do not know about Hg, or Bzr, but
perhaps there are similar solutions?
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
For whatever it's worth, and if you want to use Scmbug for SCM to
bug-tracking integration, Scmbug currently integrates with CVS, SVN, and
Git.
It is certainly possible to add integration with other SCM systems.
For whatever it's worth, and if you want to use Scmbug for SCM to