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:
On Server
bzr init (initializes the project)
bzr add (tells bzr to track all files in current directory, so please make sure you do not have unnecessary files in your project skeleton before you run this command)
bzr commit -m "initial commit" (commits the added files to bzr for version control)
On Development Machine
On your local machine, do a bzr branch project_dir
Daily routine
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 :)
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.
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
Related
Our team is looking to migrate our perforce server over to Git. Is there a way to sync check-ins from a branch in our Github Server back to Perforce to keep them in sync? I have been looking at git-p4 and there seems to be lots of documentation of how to sync Perforce -> Git but not the other way around. I would ideally like to have it syncing both ways perforce <-> git, is that possible with p4-git?
Perforce GitFusion can do this, but the developer would have to push changes to the GitFusion server instead of the github server.
For most of the time, merge conflicts were sorted out automatically. Perforce was the "master". People submitting from Perforce always had their change go straight through. People submitting from git would have their change submitted via this process:
lock master git repo
fetch upstream p4 changes
rebase against upstream p4
submit to p4 if that all went ok
That still left a very small window between (3) and (4) where someone in Perforce land could submit a conflicting change to the same files. But in practice that only happened a couple of times, over the course of several years of probably hundreds of commits per week.
In those two cases I went in and manually patched things up which was a bit clunky. I think you could just automatically discard the problematic change quite easily, but in the end, switching to git entirely made this problem go away.
Git-p4 is designed such that the git repository is initialized with data imported from Perforce. After this initial import bidirectional communication between git and Perforce repositories is fully supported, with the exception of branches/merges that have limited support.
To import updates from Perforce to git:
git p4 sync
To submit changes from git to Perforce:
git p4 submit
For more details regarding git-p4 configuration please consult its documentation.
Update: I would always advise to test any flows in temporary repositories before deploying.
In the past I setup something like this. I had a gitolite repo and a p4 server. Changes pushed to the gitolite repo would be picked up by a cron job and turned into P4 commits (via git-p4 submit). Similarly, changes submitted to p4 would be picked up by the same cron job and synced back to git (via git p4 rebase).
There were two git repos involved: the gitolite repo that normal git developers committed to, and a separate git-p4 based repo where the git-p4 operations took place.
I had a fairly small shell script to co-ordinate everything. The main tricky areas were:
locking: you have to forcibly rebase the gitolite repo so you need some way to ensure developers don't lose changes when this happens (I used a lock file).
Merge conflicts. Very occasionally two people would edit the same section of a file in P4 and git at the same time.
I have faced this problem myself and as far as I know there's nothing of the kind.
In my case I have to basically:
Create a patch for the changes in Git: git diff sha1..sha2 > mypatch.diff
Make a list of the affected files: git diff --name-only sha1..sha2 > files.list
Apply the patch in the P4 repo: git apply mypatch.diff
Reconcile changes in P4: for each file in files.list; p4 reconcile $file; done
Edit your P4 change list and then submit it (I'm sure this can be automated too but I haven't had the need for it).
I have a couple of scripts that help me with this, you can find them here: https://github.com/pgpbpadilla/git-p4-helpers#sharing-changes-git-p4
I have been using this workflow for ~6mo and it works for most cases.
Caveats
This creates a single change lists for all commits in the sha range (a..b).
I am planning to add my iOS project to GIT hub and I am new to the GIT branching and taging.
Please suggest a simple and good branching structure for development and production.
If i create one branch for development and one for production(master), is it possible to create sub branches under development?
Help is highly appreciable.
You can branch from any commit in git. All branches are equal. Why don't you try it out?
SCM organisation tends to be project-specific, so, whatever works for you is good. Your clients should never see your entire repository anyway.
First of all, branching in Git is unlike branching in Subversion or any other Central VCS.
Guess you need one major branch, and from there you can make all possible branches you need. Just remember to merge what you want to keep.
E.g. you branch for production (guess solving problems (branch even per problem)) and you branch for development (sub branching again if needed). And later on you can combine (merge) the changes from the production branch back to the master and all the stuff from your development branches that you want to keep.
But there is no best way - that depends on your use cases.
I usually branch per problem (production / issues) and merge it back if solved.
The development branch(es) I only add when needed (f.i. before acceptance testing).
YMMV.
Assume you have a tarball named ios_project.tar.gz with your initial work. You can place it under git revision control as
follows.
$ tar xzf ios_project.tar.gz
$ cd project
$ git init
Git will reply
Initialized empty Git repository in .git/
You've now initialized the working directory--you may notice a new directory created, named ".git".
Let the master be as is. I would recommend you to create two branches one for development and another for production. Do all your code modifications which you are unsure of in your development branch, and when you are sure about your work, push it to the production branch and apply a tag on it so that it is each to track the production line at a later stage.
In addition to this if you would like to share it with others, then have the repository as a shared directory. And clone it on any other development machine, create a local branch tracking the development branch on this machine, do changes, push to origin.
Following set of commands would be useful at a very basic level:
git clone git#repository_path_on_network/folder_name
git branch usrname_activity_dev --track origin/branch_in_repository
git checkout usrname_activity_dev
git add filenames
git commit -m "comments"
git push origin usrname_activity_dev:branch_in_repository
git checkout local_production_branch
git rebase usrname_activity_dev
git push origin local_production_branch:production_branch_on_repo
git tag tag_name
git push origin local_production_branch:production_branch_on_repo --tags
These are very basic commands. I would suggest you to further go through the internet. You will find a lots of commands according to every situation you are in.
Take a look at Git flow. Python scripts to help apply this are available here.
We've been using Mercurial for a couple of months now and it's improved our deployment process A LOT already. This is the good part.
The system we have in place is working but it's still error prone if you're not careful or rushing. This leave me wondering if there's ways we could improve it or... maybe we're completely off the track :)
Our environment consist of:
Local development workstation (each developer)
Development server (hosting the DB & the central repository)
An acceptance server (Where QA is done)
A staging server (Where we stage the release branch, we then robocopy to the live systems)
A little background on the reason why we switched:
We are in a work environment that often have us switching from task to task, leaving many pending tasks. Many would become stale and clutter up the main branch when we were back on CVS. Deployment was a nightmare as you had to work around lines that needed to go live and others that didn't using Beyond Compare.
Mercurial with named branches and easy merging solves this for us. So not knowing what to expect we set it up.
First we cleaned cleaned up our production source, pruning dead files, etc.
We FTP'd that on staging and made this our new repository as "default", this was to be our stable branch ready to be deployed at all time.
Afterward, we did an hg clone to the development server and had each developer hg clone from the development default branch.
On acceptance where we do QA we did an hg clone of the development server's default branch.
At this point we have a stable copy of the code everywhere, everyone is eager to start!
local machine are pushing to dev, acceptance pulls from dev and staging is completely isolated and can pull from wherever if the path is provided.
Now the idea behind this was that the default branch on our system would always be a copy of the code on the live server, provided that we remembered to pull before starting a new branch. When starting a new feature we would:
hg pull -b default #synch up
hg update default
hg branch {newFeature} #newFeature completely isolated from other changes.
*work on {newFeature}
Oh no! A bug! this is unrelated to what I am currently working on lets call it {bugFix111}. This appear to call for a new branch independant of my feature; go back to updated default. This will isolate newFeature and bugFix111 from each other and each can go live independently as they are based on default.
hg update default
hg pull -u
hg branch {bugFix111}
Once work is completed on say {bugFix111}
hg push -F {bugFix111} #send our fix to the main central repo on dev.
Go to acceptance:
hg pull -b {bugFix111} #pull the fix from the central repo (dev).
hg merge {bugFix111} #merge the code in the default QA branch.
hg commit -m "Merging {bugFix111} into default"
*QA sign off on the fix
We have to branch off acceptance - default were QA take place and release where we merge the stuff as it get signed off.
hg update release
hg merge {bugFix111} #fix is now ready to go live
hg commit -m "Merging {bugFix111} into release"
On staging:
hg pull -b release {PATH TO ACCEPTANCE REPO}
hg merge release
hg commit -m "Merging {bugFix111} into staging default"
hg tag release{date}
*robocopy to live
*run task that pull from staging to dev so that they synch up again.
This has been working for us and save up some deployment time as it's a breeze to just robocopy the stable release branch.
Issues
What we have noticed is:
It's easy to goof up a merge when merging the second time on release, this seem against the flow. We can break it after the QA sign off.
Could get QA to test our release branch as well but it seems like duplicating resource, the goal is just to have features isolated and being able to send them one at a time.
We can completely blow it up by merging release over something wrong, e.g. hg merge release when you are on the default on acceptance completely overwrites it.
If we forget to pull before starting a new branch we are working off the wrong base.
Few other oddities but those are the biggest hurdles.
I realize this is a long post, but hopefully the answers will help other Mercurial newbies like me trying to set up a decent workflow at their company.
Why not pull on staging from the QA branch? Then the merge job has already been done and validated, i.e if the commit has some manual merge you will import it on staging also. Otherwise you have to replicate the merge on staging as you are doing it now.
I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.
So, I'm just getting started with Bazaar. I am using Bazaar explorer for Windows as the GUI.
I can see how to send my changes via email, but I don't know what to do with the change file once I have it. Where do I put the change file, how do I merge the changes into the Trunk?
If I select merge, and then the folder containing the change file I get an error message that says the folder I've selected is not a branch. Pulling changes works the same way. If I place the change file in with the branch, that doesn't do anything. I'm sure it's something simple.
Thanks
Clarification:
I am not talking about compressing the whole project, emailing the compressed file, unpacking and merging. I'm talking about the export funciton mentioned here:
http://doc.bazaar.canonical.com/explorer/en/visual-tour-windows.html#export
Maybe I'm misunderstanding the purpose of the export function.
Right now I'm leaning towards setting up a VPN for anyone on the project so we can work more directly.
Even if you can't get the e-mail work flow going, I don't think you need a VPN. It sounds like you can set up an SFTP server, give each user write access to their own repository, and give them read access to everybody else's repositories. Then you can push or commit to your own branches and pull, update, or merge from everyone else's branches.
If it's not obvious how to set that up, I'd recommend you set up an account on Launchpad to play around with branches and merging. It will probably be easier to set up your own server after you and some of your team mates have gotten a little demo project working on Launchpad.
In case it's helpful, here's a summary of my Bazaar workflow on an open-source project. It covers setting up branches, merging changes, and creating merge proposals.
As explained in bug #86420, there are multiple ways a location can be not a branch, such as:
no .bzr directory
.bzr directory present, but no .bzr/branch directory
It would be helpful if Bazaar explained exactly why it does not consider a location to be a branch, because that both explains to the user what's going on (and where to look next to diagnose further), and also because it makes suggesting a likely remedy easier.
In particular, it would help bug #86402 by improving user feedback and making it easy for the system to suggest an appropriate remedy to the user.
For the case where there is a .bzr directory, but no branch in it, perhaps the error text ought to suggest the user try "bzr info" to understand what it is that directory contains instead.
You do have an example of merging from an emailed change file here. (command-line version)
# USER 1
bzr init-repository project
bzr init project/user2
bzr branch project/user2 project/user1
# USER 2
bzr init-repository project
bzr init project/user1
bzr branch project/user1 project/user2
# USER 1
cd project/user1
<do some work>
bzr commit -m "feature foo"
bzr send -o ../foo.patch # email the feature foo as it compares to the 'user2' branch
# USER 2
cd project/user2
bzr commit -m "feature bar"
bzr send -o ../bar.patch # email to USER 1
cd ../user1
bzr pull ../foo.patch
cd ../user2
bzr merge ../user1
bzr commit -m "Merge foo"
# USER 1
cd project/user2
bzr pull ../bar.patch
cd ../user1
bzr merge ../user2
...
Basically, the idea is that you have 1 branch which you explicitly label as the other user's work. When they send you a new merge directive, you go into your copy of their branch, and use "bzr pull". At this point your local branch should be an exact mirror of their remote branch. You then do "bzr merge" as appropriate into your own working branch.
The reason I start with "bzr branch user1 user2" is just to get the default target for "bzr send" set. You can just do "bzr send -o XXX ../userX" the first time, I believe it is remembered from there on out.
Also, you don't have to use "-o XXX", if you just want to start up the email program with the patch attached. (I think you need to set --mail-to in that case.)