Reputation: 7685
Where I work, we work (mostly) in pairs. We have seen the need for version control, and we will be using bazaar as our distributed version control system, due to its apparent flexibility.
After some experimentation, we have agreed that in order to set up a project, we should use the following steps:
project_dir
We are currently trying to establish a workflow that will work for us. This is what we have agreed to do daily:
- Pull down latest changes from
pull_path
- Code and commit. NB. Your commits will be saved on your local machine.
- See step 1.
- Push your changes to
push_path
(NB.push_path
=pull_path
)- If there is any conflict:
- Try bzr resolve first.
- If that fails, get your partner and do a manual resolve (open file.OTHER, file.BASE and file.THIS and make relevant changes).
- Commit your changes (bzr commit)
- Push again (bzr push)
- Repeat the above sub-points (#5) until all conflicts are resolved.
In terms of the workflow, is this the right way to do version control with bazaar? We have encountered problems where our commit comments 'change ownership' everytime the other team member pushes changes to the server. I'm pretty sure this is not how it's supposed to work, but it may also be due to certain options selected during the project setup phase.
As the VCS evangelist here, I am working on a guide to be used by the team, and particularly by new people as the team grows, and it would be great to have a 'proper' set of steps to follow in getting work done. Your contributions in establishing a nice and simple step-by-step flow to get the best out of bzr would be greatly appreciated. Please add your contributions here.
Thank you all in advance :)
Upvotes: 1
Views: 545
Reputation: 25197
What operating system(s) do you run on the server and development machines? And file systems? Windows file systems' permissions and sometimes the owner / group sometimes differ from the same files on a unix file system. That might be the first stumbling block.
Bazaar workflow:
Run a main tree on the repo server, and do a checkout locally:
bzr checkout sftp://path/to/repo/project /var/source/project
Branch the checkout locally / to your dev environment:
bzr branch sftp://path/to/repo /var/www/project
Don't work on the checkout, only work on the dev branch. Work and commit there, using the various bzr commands.
Once a work module / bug fix / task is finished, merge (not push) into the main repo:
//In /var/source/project
bzr merge /var/www/project
//Resolve any conflicts
bzr resolve
//Commit the merge
bzr commit -m "Work module | task | bug fixed"
Because /var/source/project is a checkout, the repo on the repo server will be updated automatically. This enables two or more developers to work on the same project concurrently, without needing to push and pull the whole time.
Upvotes: 2
Reputation: 5505
I'm not sure how your commit message changes ownership, if you do a merge and commit then the new commit is under the name of the guy who did the merge, but the original commits are still tracked. See bzr log -n0
Upvotes: 0