baltimore_dad

In my environment, it’s important to limit access to the vcs repository.  We need to limit general access to the code, commit access on different branches, as well as the ability to create branches in certain areas.  In this post I’m going to look at how to handle permissions to lock down/allow different operations.  Here is the repository structure I’m working with:

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
`– myProject.trunk
1 directory, 0 files

Just my trunk branch in the repository.  All of these files (the .bzr, the directories etc.) are owned by me.  I should be able to do anything I want in the repository.  Like creating a new branch.  So, I have my trunk branch, and my first release branch in the repository.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch repo/myProject.trunk repo/myProject.R1
Branched 0 revision(s).

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
|– myProject.R1
`– myProject.trunk
2 directories, 0 files

Testing with various permissions

Below is a table of various permission settings and the directory/files I applied the permissions to.  I chowned all of the files to root:wheel and messed with the global permissions.  In actual production you’d want to use some combination of group permissions/setuid bits/umasks to make sure everything works.  So, when I list the permissions below, I’m only referring to the permissions I had on  the specified directory/set of files.  x was only ever set on directories.

more »

Using push/pull with bazaar.  Before I started playing around with bazaar I spent a little bit of time with git.  Since my background has been entirely CVS I thought that push and pull were generally “special” operations in newer vcs systems.  It turns out, in bazaar push and pull do nothing other than manage mirrors of branches.  If I’m sitting in a branch and issue a bzr push command, I’ll end up with a mirror of the current branch in the push target, like so:

[andrew karma] /Users/andrew/Development/BZR/myBranch
>>>>>> bzr push ../myBranch.mirror
Created new branch.

I now have a branch called myBranch.mirror in my BZR directory.  I’m going to take a look at it now.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls
total 0
0 myBranch/        0 myBranch.mirror/ 0 myRepository/

[andrew karma] /Users/andrew/Development/BZR/myBranch.mirror
>>>>>> bzr info
Standalone tree (format: pack-0.92)
Location:
branch root: .

Related branches:
parent branch: /Users/andrew/Development/BZR/myRepository/myProject/myBranch

At this point, it appears that a pushed branch is really no different than a branch that you’ve made using the branch command.  You can use push and pull to keep the mirror in sync, as long as the branches have not diverged.  A branch is considered to be diverged if there is a check-in in the dest that is not in the source.  You can work around this by merging the dest onto the source prior to running the push, or by using –overwrite command that will overwrite the information in the target.

One thing I’m starting to notice is that there are many ways to get to the same place with bazaar.  bzr branch/bzr bind is identical to bzr checkout while bzr checkout/bzr unbind is identical to bzr branch.  I suspect that there are options to checkout/branch/bind/unbind that makes the operations a little more convenient but they really aren’t dramatically different commands.  I think that push/pull fall into this camp.  I don’t think they do much that you can’t accomplish with branch/commit/update, but they may let you think about what you’re trying to accomplish in a different way.

Below are a number of other commands that I’ve mentioned but haven’t really talked much about.  I’m not going to go through examples, just describe what they do.
more »

In the third part of this series on Bazaar I’m going to spend some time examining repositories.  The docs seem to indicate that these really facilitate sharing branches.  I was going to cover repositories and push/pull, but this seems like enough for now.

Repositories

According to the bzr documentation a repository is nothing more than the database that holds all of the branch data.  When you run bzr init, you create a repository within your branch (the .bzr directory).  There is also what the manual calls a shared repository, these are created by the bzr init-repository command.  A shared repository allows multiple branches to share the same database.  This can yield some space savings, as well as keeping everything organized.  I suspect that this organization can aid in keeping a sane permissions model.  We’ll look at that in a later post though.  For now, let’s start playing around with repositories.  First I’ll create a repository.  Remember, myRepository can use any of the remote URI specifications that Bazaar supports.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr init-repository –no-trees myRepository
Shared repository (format: pack-0.92)
Location:
shared repository: myRepository

The –no-trees option tells init-repository to not create a working-tree of the branches within the repository.  Since we won’t be working in this directory, the –no-trees option makes a ton of sense.

more »

After part 1, we know how to create, checkout, and modify a single copy of code. It’s almost no different from CVS from a normal user’s standpoint. Add, checkout, commit, status, diff, etc. all do pretty much what they do in CVS. When dealing with a team of developers this can be a good thing, as the time spent learning the basics of the new VCS is minimized. Anyway, on to the point of this post, branching.

As I said in part one I still like the idea of a central branch, a “HEAD” if you will. I think there is also a need for “official” branches. Things like maintenance branches for each release/patch should be managed. However, I think users should be free to create their own branches for features as needed. In this post I’m going to take a look at how bazaar handles branches.

Creating a branch is very simple, you just issue the bzr branch command

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch myProject myProject.branch1
Branched 2 revision(s).

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls
total 0
0 myProject/ 0 myProject.branch1/

As you can see, the branch operation created a new directory, myProject.branch1. Again, this would work with local files, remote files (via SFTP, or other protocol) as described in the documentation. Lets take a look at what myProject.branch1 is.

more »

Ok, this is going to be nothing new for those of you who have gone through the 5 minute tutorial on the bzr website. I’m going through it again here, so the rest of this follows. First, I created a directory like this:

% ls -R myProject
0 myDir/ 8 test1.txt 8 test2.txt 8 test3.txt
myProject/myDir:
total 0
0 test4.txt

All of the .txt files have the line “Initial Content” in them. Once this was setup, I did the following:

put myProject under management.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr init
Created a standalone tree (format: pack-0.92)

add the files in myProject to bzr

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr add
adding myDir
adding test1.txt
adding test2.txt
adding test3.txt
adding myDir/test4.txt

finally, commit

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr commit -m “First Commit”
Committing to: /Users/andrew/Development/BZR/myProject/
added myDir
added test1.txt
added test2.txt
added test3.txt
added myDir/test4.txt
Committed revision 1.

more »

First, some background. I work in a fast paced development shop, with a team of very talented engineers. We are currently using CVS to manage our codebase. In the not too distant past, we were actively working on as many as four different branches. Keeping code appropriately syncronized between the various branches was exceedingly difficult. I’ve been working on a little coding in my spare time, and figured now was as good a time as any to educate myself on some of the newer version control systems. I started playing around with GIT, and didn’t really see a clear line towards what I want to accomplish. Bazaar seemed to be explicitly designed to handle several different workflows. Also, it is more similar to CVS than GIT, which can be both good and bad, but things worked a little more like I expected them to with bazaar. Anyway, what do I want to do with version control?

In short I think I’d like to see a main branch, what CVS likes to call HEAD. Several release branches for maintenance, and any number of feature branches. I envision HEAD, and the release branches to be “officially” managed, while developers are more or less free to branch for features as they need to. What this requires, is some sane way to ensure that code reaches HEAD/the appropriate maintenance branch when it’s needed. With as little hell as possible. Merging branches in CVS is an f’ing nightmare.

So, given that I like what I’ve seen from bazaar so far, and a very loose idea of where I want to get, I’m going to start seeing how well bazaar fits. I’ll post what I find.