Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

[OT] Advanced CVS usage

by drewbie (Chaplain)
on May 29, 2003 at 16:15 UTC ( [id://261582]=perlmeditation: print w/replies, xml ) Need Help??

I've been using CVS for a long time now. But I've only been using the basic features. No branching, tagging, etc. So now I'm trying to take my use of CVS to the next level. Which for me is starting to use branches. I have a copy of Carl Fogel's book and have found it very useful. (BTW, there is now a second edition and the entire book is now available for free. But I'd encourage supporting the author by buying a copy.) What I would like from my fellow monks is hints, tips, and strategy on more fully utilizing the features of CVS.

There is also a new CVS book from O'Reilly coming out soon. Anyone had a chance to review the manuscript? I suspect it won't be in-depth enough for what I want since it's an "Essentials" book. But I digress...

The IT group at my employer is very small, so the developers are almost never working on the same project. An essential element of any new strategy is that we can continue to work independently. We have also begun a project to start tagging releases, which will make updating the production servers much less risky. As part of this project, we're also putting together real smoke tests and just more testing in general.

Right now we're doing all development on the trunk and uploading files as needed for a release. No branches or tags. This is better than our previous practices (no version control at all), but it could definitely be better. After a long discussion the other day, here's our current plan.

All new development will now take place on branches. When we are ready to begin working on a new project/release we create a new branch (ie. "IM 1.4"). Then we do the develpment. Once the release is ready for production, we merge the branch changes back into the trunk. The trunk gets tagged as the next stable release (ie. "0.8.1"), and the production servers are updated to this new tag.

The big advantage we found of this method is that it allows simultaneous projects to be developed without interference. So the CVS tree might look something like this:

im-1.4 (branch #2) /===========\ / \ 0.8 / 0.8.1 \0.9 (stable releases) =*===|=====|======*=========*=== (trunk) \ / \________/ (branch #1) bugfix-1

I would love to hear how other monks have setup their repositories. Currently our setup is very simple, but expect it to grow to be more complex. I'd especially appreciate insight on how to manage (very) complex setups. How do you keep up with the branches? Is there a GUI to help visualize the tree? Thanks for any advice you can give me.

Update: marked subject as OT. But we use CVS to manage our web apps written in perl so it's only 98% OT. :-)

Replies are listed 'Best First'.
Re: [OT] Advanced CVS usage
by bluto (Curate) on May 29, 2003 at 18:50 UTC
    Not sure if you've tried this, but some good information can be found by going to Google and entering "software branching patterns". The first link has more patterns than you will ever want to see.

    Also, be sure to check out http://www.tldp.org/REF/CVS-BestPractices/html/index.html, though the book you list may have much/all of this.

    I can't help with complexity. I'm the only one using my repository so I can get away with developing on the trunk. When I release I tag it and create a branch for bug fixes, which eventually get merged back into the trunk. Any very long term development I move off to it's own special branch (since I don't tend to have much of that). If others start using the repository with me, I'll may have to limit the trunk to stable releases as you have done. Though I imagine merging will be more painful.

    Even though I'm the only one using the repository, I've found it is very important to write out the rules (i.e. when to tag and branch, when to merge, what to name tags, when to retire a branch for good, etc.) so I don't start cutting corners, forgetting, and getting into real trouble. I also tend to keep a text listing of all branches, their current state (active/retired) and purpose. This is pretty low tech, but it works for me.

      Thanks for the link! The paper looks very helpful. I've already printed a copy for reading later. I'll also poke around on Google as you suggested.
Re: [OT] Advanced CVS usage
by autarch (Hermit) on May 29, 2003 at 17:37 UTC

    Advanced CVS = Subversion

    Subversion is coming along very nicely, and I've been using it for some small 1-2 person projects for a while with no trouble at all. I'd strongly suggest taking a look at it before investing too much time in CVS.

      There are several problems with Subversion in its current state, which prohibit people using CVS from migrating over to it (yes, my asbestos flamesuit coveralls are zipped up tightly):
      1. There is no import/upgrade path from existing CVS repositories to Subversion repositories. Until svn can completely import an existing cvs repository, with full branches, revisions, and historical data intact, it will not be an easy migration.
      2. There is currently no way to run Subversion without DAV or a webserver. I'm speaking from experience here, because I run a fairly high-volume public CVS repository system called SourceFubar, and the repositories themselves do not live on a server with a webserver. It just doesn't make sense to do so. Subversion (in its current incarnation) requires a webserver to operate.

      There are really only a couple of things stopping CVS from being better; atomicity at the directory level, and finer-grained control over access methods. Now with CVS having ACLs and no need to have local user accounts to have protected access to repositories, that is not such an issue. You can also have anonymous ssh access to repositories if you wish.

      There's two schools of thought about the ssh vs. pserver security "problem".

      1. Using pserver presents a security issue, because your password to log into the repository to commit data, check out data, etc. is passed in the clear, over the pserver protocol. Some see this as a major security problem. It isn't. If you have proper ACLs set up on the repository itself, where the users committing data do not have any local accounts on the box, all any attacker can do with that password is either commit more data, or delete existing data, and since it's all in cvs, you can just roll back if it happens (and connections are logged anyway, so you'll know who and where the attack came from).
      2. Using ssh is more secure, and your password can never be gleaned during a man-in-the-middle attack. Although this is true, it puts your cvs server itself at risk of further attack. Not only can you never verify the security of a client machine (what if someone else (an attacking client) decides to ssh into your cvs server with a "valid" account from the "valid" box?), but you have to give the user a local account on the server itself, which means there is much more access to the server than there needs to be. All to save from having a password sniffed?

      There are good points and bad points to either approach, but in the long run, using pserver is much safer for the code and for the server and the user's account itself. Not only is that password not the same as any other password that the user has, but since they don't have a local account on the box, getting that password gets the attacker absolutely nothing of value.

      The atomicity can be an issue, if you don't know what you're doing. I've done major CVS surgery on directories, file renames, moving entire trees of directories under other subdirectories, and so on.. without losing a single byte of the historical data. It's possible, but it takes a bit of planning to get right.

      That being said, Subversion looks good, but until someone can cleanly, seamlessly, and securely use it on a box that does not require a local account or a webserver, with the ability to import an existing CVS repository into it (full historical data intact), it will not catch on as fast as people hope.

      CVS is well-seated, and lots of very high-volume projects use it, and continue to use it every day, including myself. I've wrapped a lot of tools around my public repositories to help developers manage their code better (4 different web-based code view/diff/graphing tools, cvs statistics pages, and other tools that enhance the usability of the repositories themselves), and these things just don't exist for Subversion. I'm sure that in a few years time, they will, but right now, it would be traumatic to migrate existing codebases over to Subversion.

      YMMV though. For a completely new project where security isn't an issue, Subversion may be a perfect fit.

        I've been running svn on my laptop without going through Apache or mod_dav for at least eight months. See Single-User Subversion and the followup Multiuser Subversion.

        I'm pretty sure the cvs2svn.py program in the distribution is stable, though I haven't tried it.

      I did look at Subversion as part of this project, and I've heard lots of good things about it. It certainly has some features I'd love to have (atomic commits & easy renaming come to mind). But it seems more complex to install than CVS, and we already have a working CVS installation & are familiar with it. I also am not crazy about the fact that it requires a webserver (Apache 2 at that IIRC). We are using mod_perl w/ Apache 1.3 and I'm not very interested in adding a 3rd server into the mix.

      Subversion is definitely something I'll keep my eye on for the future. But I don't think it's the answer for right now, at least at work.

        Subversion has its own server now that can run over an ssh connection. It's just called svnserve.
Re: [OT] Advanced CVS usage
by ehdonhon (Curate) on May 30, 2003 at 19:51 UTC

    Here is a GUI to help visualize the tree.

    With regards to branching methodologies, I'm working on a project right now where we are using branches. Our procedure works like this:

    • Development towards future revisions of the software happens on the main trunc.
    • Once we get to a point where we will release a new revision, we branch off a "BUGFIX" branch. Any fixes that need to happen prior to the next revision happen on the BUGFIX branch.
    • Periodically, the BUGFIX branch is incrementally merged back onto the main development branch.
    • Occasionally, we will have a special project that needs deployed prior to the next release, but shouldn't be mixed with BUGFIX code just yet. That code branches off of the BUGFIX and then merges back in when it is done.
    • We've also developed the convention of maintaining a TAGS text file in the root directory of whatever part of the repository we branching. We keep it up to date with a description of what each tag is. We tag all releases, branches, and merges.
      That gui looks VERY slick! I'm going to take a close look at it next week. Thanks for the tip. The CvsGraph page mentions that it was inspired by a desire for a standalone implementation of WinCVS's "graph" feature (warning - very large page). So that's one more program to check out. :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://261582]
Approved by ChemBoy
Front-paged by krisahoch
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2024-03-28 21:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found