macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Making the Jump to Subversion
Pages: 1, 2, 3

4.3 Committing changes.
When you are ready to commit the changes you've made to your local work area and share them with the rest of your team, you need to commit those changes to the repository. Take a look at the status of your work area to verify what changes will be committed to the repository:




svn status

Before you commit your changes, you'll need to make sure your work area is up-to-date with the latest version of the repository (using svn update). And once everything looks ready to go, commit your project work area via the following command:


svn commit -m "Look at all the work I did" 

You can optionally select files individually or in groups by specifying them in the command as follows:


svn commit -m "Look at some of the work I did" ./README.txt 

4.4 Conflict resolution.
If you've made changes to a file, and your changes conflict with the changes it has in the repository, you won't be able to check in your changes until you resolve them (see page 28, Resolve Conflicts). When you attempt to update, Subversion will create three temporary copies of the file experiencing conflict:


filename.mine         (your version  pre-update)
filename.r<OLDREV>    (the version before you made your changes)
filename.r<NEWREV>    (the newest revision from the repository)

It is now up to you to manually edit the filename file using the other three temporary files as reference to merge the changes from your version and the new repository version. Once this is finished let Subversion know the conflict is resolved by issuing the command:


svn resolved filename

This will delete the .mine, .r<OLDREV> and .r<NEWREV> copies of the file and you will be able to proceed with checking in your changes.

Conclusion

Congratulations! You've set up an industrial-strength revision control system, one that is secure, fast, flexible, and free.

Subversion and Apache provide a myriad of options and configurations that can be tailored to suit just about any type of organization's or individual's needs. The setup described in this article is designed to get you up and running with a solid, secure configuration with as little administrative overhead as possible. I hope that once you become comfortable with this basic configuration you will explore the many ways of enhancing your use of Subversion.

Related Reading

Version Control with Subversion
By Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato

Resources and Tips

Some useful resources and links:

Things to Do

Things to Watch Out For

Some applications that store documents as directory bundles may delete the .svn folder that Subversion uses from inside the bundle directory. EOModeler will delete the .svn directory when you save your document. This is annoying but not difficult to work around -- when you are ready to check in your changes, if Subversion displays the status code '~' (meaning: versioned item obstructed by some item of a different kind) perform the following steps (based on a model named MyModel):


% mv MyModel.eomodeld MyModel.mine 
% svn update MyModel.eomodeld
% mv MyModel.eomodeld/.svn MyModel.mine/
% rm -r MyModel.eomodeld
% mv MyModel.mine MyModel.eomodeld

An important note for former CVS users: Use svn status where you would have used cvs update to check the status of your work area. Use svn -u status to include working revision and server out-of-date information from the repository.

When Things Go Wrong

  • Read Version Control with Subversion, see the subversion online resources, mailing lists, FAQs, etc.
  • You made a backup, right?
  • Send me an email and I'll try to help.

Adam Swift is a longtime software engineer, developing WebObjects applications since its first release, and Cocoa software since it was called the AppKit on his NeXT slab, circa 1991.


Return to MacDevCenter.com.