Re: tortoiseCVS and FM files

[Laura Lemay <lemay -at- lauralemay -dot- com>]

I think you've got some conceptual problems with how CVS works and  
that's the causing many of your problems.  It's different from other  
source code control systems, and confusing in many ways.

Checking out in CVS (the cvs checkout command) just creates a local  
working directory full of files.  It isn't like other SCC systems  
where a "checkout" gives you a locked local copy of a file for  
editing.  You should only need to check out a directory or a module  
once, to get a local copy.  You may need to re-checkout if you really  
mess up your working directory, but usually you just do it once.

So how *do* you lock a single local file in CVS for editing ("check  
out" a file in every other SCC system?)  Usually, you don't.  The CVS  
model is that anyone can edit any file at any time, and then when the  
changes are committed, you merge your changes with any changes any  
one else has made.  Its a collaborative system, not one in which a  
single person owns a single file.

This is obviously more difficult for binary files, where if multiple  
people work on the same file you can accidentally  overwrite each  
other's changes.  I've fortunately only worked with small doc groups  
where we were able to informally agree who was working with which  
file at which time.

A quick google would indicate that it is possible to turn on locking  
for CVS (you would use use cvs edit to check out a file for editing)  
-- but you have to turn on "file watch" for the entire repository to  
get that feature.  You can't enable it for just a few directories or  
modules.

The other issue I think you've got is tagging.  Tags are markers for  
files in time;  you don't use them to get working copies of files.   
You do use them if you want to get a specific version of a file  
sometime in the past (usually a release version).  So, for example,  
if you were creating a document for Product X you might check in  
working copies of that file for alpha and beta and then 1.0, and tag  
the file for the 1.0 release.  Then when you worked on it for 2.0 you  
might make changes and check it back in again for alpha and beta and  
2.0, and tag it again for 2.0.  The tags would let you easily get the  
1.0 or 2.0 versions back out again.  You can always of course get a  
previous version by date or by CVS's internal document version  
number.  The tag is just a shortcut.  Personally:  I've rarely used  
tags.  Plain old document archiving works better than CVS tagging for  
getting old copies of docs, IMHO.

I've used CVS for docs at a bunch of jobs now.  It's not exactly the  
best of SCC systems, but it does work.  It's
definitely better than no system at all.

Laura


-- 
*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^
Laura Lemay     Killer of Trees     lemay % lne.com    lemay % gmail.com
http://www.lauralemay.com                     http://blog.lauralemay.com
*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^


On Jan 31, 2008, at 11:26 AM, Rédactrice Technique wrote:

> Hi again,
>
> Just to specify,
>
> I was planning to commit doc changes to CVS only once a project was
> finished. So, for example, if a new version of XYZProduct was  
> developed by
> our engineers, I would check out XYZProduct Reference Manual v138,  
> make all
> the changes required and then check the manual back in as XYZProduct
> Reference Manual v139. I'm planning to use my allocated server  
> space for
> backups between CVS checkins (mostly because it seems a lot less  
> complicated
> to just copy the folder and dump it on the server, rather than  
> doing fiddly
> things with CVS). So I wouldn't require inter-versioning tags.
>
> Thanks,
>
> RT
>
> 2008/1/31, Rédactrice Technique <redaqtechnique -at- gmail -dot- com>:
>>
>> Hi folks,
>>
>> Well, contrary to my personal preferences and wishes, the team here
>> decided that using CVS to store my docs would be a good idea. They're
>> already using CVS for code, and didn't want to migrate to SVN or  
>> spend the
>> money on a new versioning system.
>>
>> So anyway, I'm using TortoiseCVS and have just committed the first  
>> lot of
>> my FrameMaker 8 books. I have set up a five-layer directory  
>> structure for my
>> books, so, for example, I have: Tech Documentation (Module)
>> .ProductType
>> ..ProductName
>> ...BookType
>> ....FM book and various book files.
>>
>> I then tagged the folder for each book with the version number, so  
>> for
>> example the folder Product Name Reference Manual is tagged v381.
>>
>> After a half-hour's test, I've already run in the following problems:
>>
>> It seems I can only check out my entire documentation directory every
>> time, and not just a particular book's folder.
>> I've tried to get round this by selecting Revision - Choose branch  
>> or tag,
>> but none of my carefully applied tags appear in the list, even  
>> after doing
>> an Update list.
>> Which begs the question, even if that worked, should I be tagging  
>> each
>> file with the product name as well as the version number, as I'm  
>> obviously
>> going to have multiple books with the version number v100?
>> If I drill down into the checked out folders, I can do a check-out  
>> using
>> the tagged version, but it check out the whole structure again, so  
>> that I
>> end up with:
>>  Tech Documentation
>> .ProductType
>> ..ProductName
>> ...BookType
>>  ....Tech Documentation
>> .....ProductType
>> ......ProductName
>> .......BookType
>> ........FM book and various book files.
>>
>> Is there any way around this?
>>
>> In addition, my Framemaker books are all labelled with the version  
>> number,
>> i.e., ProductName Reference Manual v3.8.1. So each book file and
>> associated generated files (TOC, LOT, LOF) are then treated as new  
>> files by
>> CVS. I don't want to get rid of the version number from the book,  
>> as I find
>> it useful if I have two version open at the same time, but CVS is  
>> treating
>> these differently-versioned files as new files every time. Is  
>> there anything
>> I can do to make this better?
>>
>> I apologise for the specificity and length of this mail, but  
>> frankly, I'm
>> on the verge of bursting into my boss's office and screaming, "I  
>> TOLD you
>> this was a ********* stoopid idea!" ;-)
>>
>> Thanks in advance,
>>
>> RT
>>
>


-- 
*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^
Laura Lemay     Killer of Trees     lemay % lne.com    lemay % gmail.com
http://www.lauralemay.com                     http://blog.lauralemay.com
*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.