Re: tortoiseCVS and FM files

Subject: Re: tortoiseCVS and FM files
From: Laura Lemay <lemay -at- lauralemay -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 31 Jan 2008 12:40:34 -0800


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.


Previous by Author: Re: permalancer
Next by Author: RE: Interview Follow-Up
Previous by Thread: Re: tortoiseCVS and FM files
Next by Thread: RE: tortoiseCVS and FM files


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads