Discussion Leader: BenjaminChiao

Key Features:

• allows multiple developers to work on the same code base
• keeps a record of changes made over time
• permit reverting to previous versions. You can dial in a date and see the snapshot on that date
• support multiple releases of your software at the same time as you continue with main line of development. There is no longer a code freeze just before release.
• tells you the differences between different versions

To Try things out:

It will not be trivial to have some hands-on experience without some setup. If you are interested, first try download a frontend such as: http://www.tortoisecvs.org/download.shtml∞ and using it to connect to any cvs repository.

Key commands/concepts:

workspace--subset of the code that you need to make your changes

modules--the repository administrator can divide a project into modules. To facilitate a convenient checkout, files within the same module can be checked out by name. The files and modules are in a many-to-many relationship. That is each file can belong to many modules; each module can contain many files. Similarly, projects and modules can be in many-to-many relationship too.

update--you update your workspace before committing changes so you don't overwrite the changes on the same files other people have made changes

check out--you extract files from a repository to your workspace

commit--you save your changes back to the repository

merge--different lines of development can brach off the mainline of development. To reconcile changes redundant in braches, you can instruct cvs, for example, to write a bug-fix to all braches that are affected

lock--strick locking: only read-only copies can be extracted if the copy has already been checked out by other person.

Optimistic locking -- requires issueing and update before committing, basically meaning no locking.

Connection to readings

Community of Practice

while the commands are standandized in cvs, each project can and needs to form its own convention of how to tag files.

tags--symbolic names chosen by users to name files within the same braches, before and after bugfixes, etc.

Each open source project also has its own convention about deciding who have authorization to commit changes. Wenger mentions one key dimension for a community is a shared repertoire. The other two key dimensions being joint enterprise and mutual engagement. The open source communities provide an extreme case to understand some aspects of how the relative weights on these three dimensions would affect the characteristics of a community.

The open source community is an extreme case because its shared repertoire is almost exclusively recorded electronically.

Group Ties and Leadership

Forking is referred to as taking a open source software package and developing it in a possibly different direction to achieve possibly another goal or purpose.

One special feature of open source communities is that any one can take the whole code by forking. It constrasts with a split of a company in which certain fixed assets are hard to move. The question for forking is almost only related to move of soft assets (namely people who know how to use the intellectual property).

It is then important to ask what causes the group to split. In Sassenberg's term, is it the common identity or common bond that breaks? Or in Hogg's article, what are the typical causes of polarization and especially those that lead to new leadership?

Note some barriers of forking:

• the quality of a project (and thus implying the effort level that you forsee to input) could possibly be higher if there were no forking because the bug-fix speed could be viewed as a linear function of number of participants.

• is it moral to fork? If yes, will you still get the soft assets if you fork.

comments

I think we're all familiar with the basic principles here thanks to Track Changes in Word.