version control

I need help understanding the workflow for database version control because what I am doing now is not working.

When I am on a branch (1), and about to commit, I do a Drush @alias sql-dump, which creates a dump file in a particular directory in my repo and uses a specific name, per instructions in the aliases.drushrc.php file. Then I commit and the sql-dump is added to the commit. I see the messages and everything is working fine.

Abstract

Although Drupal has switched to Git for its Version Control needs for about an year, yet the workflow is by and far patch based, when it comes to collaborating. While some choose the path of creating sandboxes and then create an issue in the main project, yet we are far from using the power of distributed workflow that Git offers us. The following proposal aims at providing the base of using Git-like workflow while collaborating on projects.

Previous Discussion(Summary)

The detailed description of repo-families can be found here[2].

Abstract

The Version Control API is an engine for Drupal integration with a variety of version control systems. It delivers an interface to these systems for use with various development-oriented modules, like Project.

Short description

The Version Control API allows development-specific modules to interface with the server side of version control systems. We currently still lack the ability to really see what’s going on with a repository.

An activity stream is an overview of all actions in a system that are interesting to a user from his or her perspective.

This project includes a complementary module to the Version Control API that logs every change to every repository, displaying them and processing statistics about them.

I have been reviewing the various documentation (http://drupal.org/node/803746) and blog posts oriented towards site builders on this topic over the last few days, and it seems there are many very different recommendations a approaches to building sites with git. There is an opportunity here to shape some best practices that will both make everyone's lives easier in the long run, but also encourage contribution back to the community as a standard part of building any Drupal site.

Hey all,
I've been scouring the web & forums for a foolproof method to merge databases from multiple developers. If I have developer 'A' working on theming certain parts of a site and developer 'B' working on theming others, I need a way to keep all changes in sync.

I have an SVN repository set up to handle web files. This works great for files but I cannot find a similar system for keeping my databases in sync.

I know there are several modules out there to assist with this (DatabaseScripts, Deploy etc) but none of these seem to offer a full, comprehensive solution.

This is a long post, grab a cup of tea... (or better still a beer)

I manage a small team (currently 3 soon 5) of grographically distributed developers developing and maintaining a few (currently 4) projects in different stages of the lifecycle. I am familiar with managing teams developing web applications but up until now my Drupal experience has been largely solo. Developing large Drupal projects and working in a team is relatively new to all the other devs so I see this as an opportunity to encourage a sound development process using the appropriate tools.

Thank you Adrian for a great presentation at Drupalcon today! Since we didn't have time for questions I'd like to ask you quickly about something that I kept thinking about during your talk:

How does this fit into a workflow like mine where I develop and maintain sites using a SVN repository? I usually do both development and upgrading of my sites locally and then commit the changes before going to my staging or live sites and update them with SVN. Do dev or staging servers have a place in Aegir? How do you do it?