This group provides one purpose:
Coordination about whether and how the Drupal.org code repository should be moved away from CVS to something else.
Note that as of fall 2007 this is largely a moot point - until Drupal.org is upgraded to Drupal6 there is no bandwidth among the infrastructure maintainers to handle this project. To move forward sooner would require surprising amounts of coordination and effort on a new contributor's part. Of course, discussion and work towards this end (via the revision control API module) will pay benefits now and down the road.
Before writing here, be sure that you are familiar withthe many posts by jpetso about revision control systems the new release system and our issue tracking system.
Version Control API and family changes
Overview
This project objective is provide all tools to make it easy a possible drupal.org migration to another Version Control System(aka VCS). By the way, after this, drupal VCS's interaction will be improved, so it provides more flexibility to use it as project managment system for development.
This propose started like a jpetso propose.
Introduction
Some drupal.org developer tools, like the auto-releasing module versions feature, are CVS dependent, which is one of the reasons why drupal project is using CVS now.
Drupal developers are used to recognize others work, so it would be really natural to use a Distribututed Version Control System(aka DVCS) where this concept is implicit(authors and commiters can differ).
On GSoC 2007, Jakob Petsovits developed Version Control API, making it possible to integrate various VCS backends in drupal.
I'm really interested on VCS's, and specially dreaming about commiting to drupal with git(that's why I wrote a guide for maintainers).
Now, there are some details that make Jakob solution not production ready, so I want to take it all to this state.
Updating "why drupal use CVS" FAQ
Trying to find a way to convince some of my class students, I found a solution on top of mysysGIT, tortoisegit, already usable since march 2009 :D
So, now git has an option as "usable by tortoise like users".
Read more
Version Control API BoF session
For everyone at DrupalCon - just in case you missed the BoF wall or the DrupalCon BoF forums - well, you guessed it: there's a Version Control API BoF taking place on Friday at 3:45, in room 141 of the convention center. Be there, or be triangular!
Read more
msysGIT = tortoiseSVN
Hi! please try to look at these sites.
I'm trying to learn git now using windows.
Download at http://code.google.com/p/msysgit/downloads/list
Guide at http://nathanj.github.com/gitguide/
Unofficial repo at http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs
Video tutorials at http://gitcasts.com/posts/git-on-windows and http://www.vimeo.com/2111264
development set up guide at: http://www.versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-gi...
and http://www.ruzee.com/blog/2008/10/drupal-development-and-deployment-usin...
Thanks!
Read moreVersion Control API in Drupal 6 and beyond
It's been a long time since I last posted an update on the state of the Version Control API, assuming we disregard short teasers on Planet Drupal. Since this last article, Version Control API nearly died during my attempts to wholly restructure the data model for practically everything involving commits, branches & tags (now unified as "labels") and repository items (= files and directories). Luckily, the story has come to a good end. Well, "end"? Depends.
Read more
Subversion 'mirror'
We recently set up a public Subversion repo automatically tracking some of D.O. CVS. Module/theme selection is quite limited (~150 modules, 10 themes) -- more modules will be added upon request. We especially like using it with a private project repo and svn:externals, pulling in all the standard modules and their dependencies (e.g. devel+Krumo+FirePHP).
Please do give it a spin and let me know how you feel about it:
http://subversible.com/
http://subversible.com/svn/
cvs contrib procedure
When I gained cvs access, I read the drupal book pages on cvs and also merlinofchaos blog, and polled irc drupal-support.
What I came up with was that there are 2 ways of maintaining releases for contributed modules.
1) Always have the latest code in head, and only release a branch when the new version of drupal comes out. For example when working with module and it is for drupal5 the code is found under HEAD, when the module is upgraded for drupal6, create a branch DRUPAL-5 for the drupal5 module.
Read more
What is biggest drupal project you have ever managed ? (size in man-days)
Refactor revisions to use a version control system
Proposal added to official ideas list at http://drupal.org/node/237619
The node_revisions table currently stores a full copy of everything for every revision.
For space considerations it would make a lot of sense to store it as diffs instead.
Many sites like drupal.org also have issues with simultaneous editing - using diffs might allow for merging of edits rather than the current locking system.
Note that in D7 core, node_revisions may well be handled similarly to CCK fields - so something extensible to both models is likely to have the most chance of future use.
Read moreState of the Version Control API
Yeah, those were the times. Weekly status updates during the Google Summer of Code... well, I'm too lazy to do that when I'm not forced to :-P
Let's see... the version control api term says that the last status update was in September '07. Way too long ago. So what's up going on in the Version Control API realm at the moment? Lots of good stuff. (Read on! It's just the <!--break-->.)
User authentication in non-CVS repositories
How to grant access to repositories at all is an important issue, and it potentially comes with a slight regression compared to the current work flow for managing CVS accounts. One advantage of CVS is that it's easy to administer - in terms of user accounts, that would be a simple "passwd" file that contains all usernames that are allowed to commit. Dead easy to generate, and at least possible to keep in sync even in an automated way. However, more recent version control systems are less nice to handle - also caused by a better eye on security concerns. An overview.
Read moreCommit restrictions in distributed version control
I just spent some time in #git to further investigate how our CVS access control scripts would translate to distributed version control systems, in order to help determine the right direction for our new GHOP-powered Git and Mercurial backends (currently being worked on, more on that to come later). Short answer: keep out of that altogether - it's not DVCS style to restrict project maintainers like that. Read on for a more detailed analysis.
Read moreTODO list: Eventual Version Control migration for drupal.org
This is a loose checklist of items that need to be taken care of to get Version Control API working on drupal.org. The bulk of the required work has been done, and the current plan is to get the 6.x-1.x branch deployed on drupal.org before the d.o redesign is done.
- Script for migrating from cvs.module to versioncontrol_cvs -- partially done
http://drupal.org/node/346362 -- Print warning message after branch creation to update workspace (port over from cvs.module)-- done
Version control wrap-up, part 1: modules
It's over! Google Summer of Code 2007 had its official "pencils down" on Monday, 19:00 UTC - which was 21:00 at my place, perfect for a last sprint... but I digress. According to Google, mentors are supposed to evaluate projects based on the state that they were in at that time. Which means it's time for me to wrap it up and explain what I achieved in those two or three months. In addition to these writings, I set up a test site at http://www.petsovits.at/versioncontrol/ where you can try out most of these things in action.
The wrap-up is becoming too long to conveniently fit into one single blog entry, so I'll split it up into two halves. This one basically covers the hard facts: which modules I wrote during the Summer of Code, what they do, and how they work. (Part 2 is now also available.)
Read moreMercurial findings
So, Mercurial, or "hg" in short. One of the two revision control systems originally written for being the Linux kernel's BitKeeper replacement - in the end, git was chosen for that job, but Mercurial lived on nevertheless. The requirement of being suitable for kernel development implied two features: performance (although git is still a tiny bit faster) and distributed development methodologies. Both are also present in git, and in fact, the two systems are very similar in scope, paradigms and usage patterns.
While git is written in pure C, Mercurial mostly consists of Python code, with only small, critical code paths implemented in C. This has benefits for Mercurial's portability, as can even be observed with other SoC students. git is pretty much focused on just Linux, whereas Mercurial can also be installed more easily on Windows and other Unixes. Not that straightforward graphical tools are yet as mature as the ones that exist for CVS or SVN.
Read moreCVS, the veteran workhorse
CVS, or Concurrent Versions System, was the de-facto standard open source version control system for a long time. It came up in the late 80s and grew popular enough to manage the source repositories of virtually all open source projects until only a few years ago (when Subversion started to take over). It's still widely used, including on drupal.org, but hardly deployed on newly created repositories anymore. Development is strictly fixed to a centralized client-server methology, and while distributed version control systems (or Subversion with svk) strive to make a checkout independent from the server, with CVS you're completely dependent on a fast and reliable connection to upstream.
In summary, there's little surprises in this CVS coverage, especially for the resident drupal.org admins. But necessary nevertheless, if only for later reference. Obviously, no new requirements for the API module were found, as the CVS setup on drupal.org together with the Project module is the status quo at the moment.
Read moreA peek at Subversion
My project definition says that I still got to document the specifics of SVN and CVS (git has been taken care of). Coming from the KDE camp, I'm already acquainted to Subversion to a certain degree, as the whole huge KDE repository switched from CVS in May 2005. (No one, including the SVN admin, did regret the switch).
Subversion (SVN) came up as a replacement for CVS - motto: "CVS done right" - and incorporates its centralized development methology and its straight-forward workflow, while improving on its weak parts. Compared to CVS, Subversion features good stuff like atomic commits, renaming, serverless diffs, symlink support and version-controlled directories, to name the most popular ones. It fulfills its role as a drop-in replacement brilliantly and has kinda deprecated CVS, at least for newly installed repositories. (That, of course, doesn't stop Linus Torvalds from claiming that centralized development methologies are outright wrong.)
Read moreGit scrutinized
There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.
For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.
As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.
Read more