Anyone used Tortoise CVS with Frame Files

[Combs, Richard]

Neil Tubb wrote: 
 
> Just wondering if anyone out there has used the open source 
> Tortoise CVS with Frame files? I'm looking into it as a way 
> to introduce some simple version control for our cust docs 
> (just simple check-in, check-out...obviously no merges or 
> anything like that). Any info would be appreciated.

Lots of good replies, but there's one thing no one has mentioned
(although Mark Barratt alludes to it): Tortoise isn't a version control
system. It's a client, an _interface_ to version control systems --
specifically to the venerable CVS and the upstart Subversion (SVN). 

We're switching from CVS to Subversion here, but Tech Pubs doesn't check
in FM files. We only check in the PDFs and help files that go into the
build. The engineers here echo Mark's comments about Subversion's
superiority to CVS. 

I've been using Tortoise clients to access both CVS and SVN for a while
now, and I can vouch for Tortoise -- it's much better than WinCVS, which
I used to use. 

As for Hedley's question: 

> Martha:
> 
> >  I use TortoiseCVS with Frame files. I mark both .fm and .book files

> > as binary, so that each time I check in the entire file is replaced,
> 
> And if the product manager has just decided to restore the 
> functionality that was removed a few days ago, how do you 
> retrieve the version of the FM file that contains the content 
> you deleted when the function was removed? 

Martha misspoke -- when you check in, the file isn't _replaced_, the new
version is _added_. Every version you check in is available in the
repository. That's why file space quickly becomes an issue with binary
files -- unlike code (text files), you're not just checking in the
diffs, you're adding a whole new copy of the file. If you do that every
day with lots of FM files, the repository admin may shoot you. 

I don't know anything about the "binary diff" capability in SVN that
Mark mentioned. I'm not sure how that would/could work, and I probably
wouldn't trust it. ;-) Since we only check in the final docs (PDF and
help), it's typically only one check-in per software release and space
isn't really an issue.

Richard


------
Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
------
rgcombs AT gmailDOTcom
303-777-0436
------