"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Archives de la catégorie ‘bazaar’

Quelques nouvelles de python: python 3.1a2 release, switching to mercurial, pycon 2009

Publié par patrick le avril 5, 2009

Gestion de versions: la gestion des sources de python passe de subversion à mercurial !.

  • http://sayspy.blogspot.com/2009/03/why-python-is-switching-to-mercurial.html (‘Starting at PyCon 2008 thanks to Barry Warsaw and the Bazaar team I started thinking about moving Python over to a distributed version control system (DVCS). While I wanted to get offline commits for the benefit of non-core developers along with easier merging from 2.6 to 3.0 (ah, the days when there are only three branches under development), I knew that would not necessarily be enough of a reason for others to switchBased on the results of that survey where git was clearly the most disliked tool of the core developers, having the weakest Windows support, and not being implemented in Python, I decided to eliminate git from the running and announce its elimination at the first lightning talk at PyCon.When I arrived at PyCon pretty much everyone asked me about the DVCS PEP. People wanted to know how it was going, who was going to win, and giving me support/pity for what I was going through. Guido noticed this and decided to end my misery by saying he wanted to make a decision by the end of PyCon. I said I was fine with that as one was already about to be eliminated and I knew my personal preference at that exact moment aligned with Guido’s…So Monday morning came around and I walked into the sprint. I asked Guido if he was ready to make a decision. He said yes, we both said hg, and so Guido tweeted the decision before telling python-dev that we chose Mercurial…Obviously community preference as shown at PyCon played a role. No one wants to choose a DVCS that causes the community to not want to contribute to Python. And I would never choose a VCS that would cause Guido to not want to work on Python. Some people seem surprised that something non-technical played a role, but ignoring social issues is to ignore how much open source is a social phenomenon. And we are not the first project to take social preference into consideration: I know both GNOME and Pinax chose git because their developers preferred git. And there are technical reasons. Having hg being faster than bzr by 2x to 3x does matter to some extent. No one wants to cause someone to not contribute because they didn’t want to wait for a checkout. And having personally experienced long checkout times because of a subpar connection to a specific server I know this can occur. The performance margin between hg and bzr is within reason typically and is not a flat-out deal-breaker, but it doesn’t help either. Bazaar also has its short timespan of format stability working against it. The tool has changed its format at least three times based on what the man page says (1.0, 1.6, and 1.9). Mercurial, on the other hand, has been stable since I think it went public or near that time. They take great pride in the fact they have not changed it. And that stability more aligns with python-dev’s sensibilities regarding stability. Once again the Python community stands out as being friendly and understanding about stuff like this with no one really seeming to be upset that we made the decision we did.’)
  • http://mail.python.org/pipermail/python-dev/2009-March/087931.html (‘Dear Python developers,The decision is made! I’ve selected a DVCS to use for Python. We’re switching to Mercurial (Hg). The implementation and schedule is still up in the air — I am hoping that we can switch before the summer.’)

A voir

Pycon 2009

  • http://pycon.blogspot.com/2009/04/all-pycon-2009-videos-uploading.html (‘The video team has pulled the trigger and all the video from the conference is being uploaded now. At the time of this post about 14 talks are now online. By the end of the day Friday, almost everything should be available (with a few minor exceptions). The videos are also integrated into the PyCon Schedule App as well, with a minor lag time. Just look for the tiny video icon: .
    Congratulations to the entire PyCon US 2009 volunteer video team for performing this Herculean task. In total 2.2TB of video, covering 168 hours of material, were collected, edited, transcoded, and uploaded. This is divided into 96 hours from the tutorials and 72 hours from the main conference
    .’)

A voir

Python 3.1a2 release

Publié dans 2009, bazaar, Gestion de version, Git, mercurial | Tagué: , , , , | Leave a Comment »

Systèmes de gestion de versions: subversion, bazaar

Publié par patrick le mars 22, 2009

Beauccoup de mouvements encore autour des systèmes de gestion de versions distribuées git, mercurial et bazaar:

- http://arstechnica.com/open-source/news/2009/03/sourceforge-adds-support-for-new-version-control-systems.ars (‘SourceForge has launched support for Git, Bazaar, and Mercurial, the three most popular distributed version control systems. The site has also added an impressive new hosted application feature which will allow users to run various open source project management and collaboration services—including Trac, Mantis, and phpBB—on SourceForge’s infrastructure. Although SourceForge was once the dominant collaboration service for open source software, its relevance declined sharply over the past few years as it stagnated and lost ground to emerging competitors. The trend towards distributed version control systems (DVCS) looked like it would be the final nail in the coffin, but now SourceForge is preparing to make a major comeback. The Web service has gained support for Git, Mercurial, and Bazaar, the three most popular distributed version control systems. This brings the site’s total number of supported source code management technologies to five, including its existing support for CVS and Subversion. DVCS is a major technical advancement in the area of source code management. The approach offers developers an unprecedented level of power and flexibility. The three major DVCS systems have all been used to build robust project management and code hosting services—such as GitHub, Launchpad, and BitBucket—which are rapidly displacing SourceForge. Here at Ars, our Web ninjas use GitHub extensively for managing the source code that powers our website. I personally use Launchpad for several of my own projects.’)

Passage de CVS à subversion pour la documentation Debian (il y a un an mais mieux vaut tard que jamais pour que le signale :))

- http://www.ouaza.com/wp/2008/03/03/ddp-went-svn-webml-might-follow/ (‘The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS. After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done. Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back. :-)‘)

Passage de sourceforge à launchpad (https://code.launchpad.net/mailman)

- http://blog.launchpad.net/general/why-launchpad-for-mailman (‘Over the last 18 months, I’ve moved GNU Mailman development from SourceForge to Launchpad.  The reasons are varied. Mailman was one of the first projects hosted on SourceForge ages ago.  I think our project id is a pride-inducing low 103, and we were even highlighted as its Project of the Month at one point.  Of course SF itself uses Mailman to serve its own mailing lists.  While the SF guys have always been great (including providing assistance during the migration to LP), I just became increasingly roadblocked by it.

The first major motivation for moving was Bazaar. This is of course the GPL’d distributed version control system developed by Canonical and used for code hosting on Launchpad.  Having come from decades of SCCS/RCS/CVS/SVN use, distributed version control systems in general and Bazaar in particular have been an enlightenment on the order of learning Python.  I mean, who’d have thunk a version control system could be fun?

After we moved code hosting to Bazaar on LP, evaluating the other benefits of Launchpad became easier.  Truth be told, there was (and still is) some resistance in the community to moving to LP because Mailman is a GNU project but LP is not open source.  That’s being fixed. The next service to migrate was the tracker, and thanks to the excellent assistance of my colleague Graham Binns, we were able to migrate the SF issues to LP.  For years, even before I joined Canonical, I let the Mailman tracker languish because I found it so difficult to use.  The simplicity and power of Launchpad’s tracker really shines for me here, especially with its ability to link across projects and artifacts (e.g. branches linked to bugs).’)

A voir:

- http://sourceforge.net/softwaremap/trove_list.php?form_cat=646

- http://en.wikipedia.org/wiki/Subversion_(software) (‘Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS). Subversion is well-known in the open source community and is used on many open source projects, including Apache Software Foundation, KDE, GNOME, Free Pascal, FreeBSD, GCC, Python, Django, Ruby, Mono, SourceForge.net, ExtJS and Tigris.org. Google Code also provides Subversion hosting for their open source projects. BountySource systems use it exclusively. Codeplex offers access to both subversion as well as other types of clients. Subversion is also being adopted in the corporate world. In a 2007 report by Forrester Research, Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and a strong performer in the Software Configuration and Change Management (SCCM) category.[1] Subversion is released under the Apache License, making it free software. ‘)

- http://subversion.tigris.org/development.html (‘ The best way to get involved in Subversion development is to submit a patch to fix a bug or add a new feature. If you don’t know what to write a patch for, have a look at the list of open issues. Subversion development discussion takes place on the mailing list dev@subversion.tigris.org. You don’t need to subscribe to the list just to submit a patch or two, but if you want to be involved with Subversion development on a regular basis, you should subscribe. It’s high-traffic, but threading tends to be fairly disciplined, so you can ignore conversations you aren’t interested in. For real-time chat, developers use the IRC channel irc.freenode.net/svn-dev (some also hang out in the user-support channel, irc.freenode.net/svn).’)

- http://svnbook.red-bean.com/ (‘This is the online home of Version Control with Subversion, a free book about Subversion, a new version control system designed to supplant CVS. As you may have guessed from the layout of this page, this book is published by O’Reilly Media. This is a place to read HTML and PDF versions of the book (although you can certainly buy a copy if you’d like to). We’ll do our best to keep the site up-to-date. As Subversion development continues, the product will continue to grow new features, and we plan to continue documenting those changes.’)

- http://svn.collab.net/viewvc/svn/trunk/ (sources de subversion)

  • - http://subversion.tigris.org/hacking.html
    • http://subversion.tigris.org/hacking.html#branch-based-development (‘We prefer to have development performed on the trunk. Changes made to trunk have the highest visibility and get the greatest amount of exercise that can be expected from unreleased code. That said, trunk is expected at all times to be stable. It should build. It should work. Those policies, combined with our preference to see large changes broken up and committed in the smallest logical chunks feasible, and applied to particularly large changes (new features, sweeping code reorganizations, etc.), makes for set of rules that are almost impossible to keep. It is in those situations that you might consider using a custom branch dedicated to your development task. The following are some guidelines to make your branch-based development work go smoothly…

      Branch creation and management

      There’s nothing particularly complex about branch-based development. You make a branch from the trunk (or from whatever branch best serves as both source and destination for your work), and you do your work on it. Subversion’s merge tracking feature has greatly helped to reduce the sort of mental overhead required to work in this way, so making good use of that feature (by using Subversion 1.5 or newer clients, and by performing all merges to and from the roots of branches) is highly encouraged.’)

    •  svn co http://svn.collab.net/repos/svn/trunk  (intéressant, il y ade très nombreux scripts python)
    • à suivre…

Publié dans 2009, bazaar, Gestion de version, subversion | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 74 followers