TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
RE: Git for Tech Pubs [was FW: L@@king for recommendations for a doc source-file management system....]
Subject:RE: Git for Tech Pubs [was FW: L@@king for recommendations for a doc source-file management system....] From:"Janoff, Steven" <Steven -dot- Janoff -at- hologic -dot- com> To:Robert Fekete <fekete77 -dot- robert -at- gmail -dot- com>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 26 Nov 2018 19:04:30 +0000
Thanks, Robert, and all, for the suggestions on this thread.
Iâll need to take some time to digest all of the great information, and will follow up with thoughts/results.
Steve
On Thursday, November 22, 2018 11:46 AM, Robert Fekete wrote:
Hi,
You don't necessarily have to store everything in a single git repository, it depends on how you slice your stuff. For example, we have a separate repository for each product.
And even if you have lots of binary files such as AI/Indesign stuff, it might be that most of the binary thing changes rarely, so chances are that only seldom will want two writers modify them at the same time. But if they are working on the same set of docs, they should know about what the others on their team are working on anyway, so they can avoid such conflicts easily.
Also, note that it is possible for multiple writers modify the same text file simultaneously, as long as they don't change it at the same place, and use the same general formatting (for example, same editor settings, and so on). Git can handle such things.
HTH,
Robert
On Wed, Nov 21, 2018 at 8:03 PM Janoff, Steven <Steven -dot- Janoff -at- hologic -dot- com<mailto:Steven -dot- Janoff -at- hologic -dot- com>> wrote:
Robert F.'s reply sounds hopeful.
Mark, to answer your original question (and thanks for all the details), we have a combination of Flare projects with lots of graphics (we're using centralized source control), FrameMaker files, Word, InDesign, and then the various image file formats, PNG/JPG/GIF/BMP/TIF, plus image source files in AI, PSD, INDD, etc., plus PDFs and more.
Lots of binary stuff, I guess.
Also might be adding videos.
The thing that baffles me is that the Flare folks seem to be moving toward Git. Their cloud-based manager (Central) uses Git. Maybe I should ask them. I just can't help thinking that, as Tony says, these repos are just going to become bloated with image files and such. The image I have is of 5 or 6 writers (or more) carrying around this massive repo on their desktops. Maybe I just don't see it right.
We have been doing some work with Git but not as the main source control for major projects.
Thoughts are most welcome. I need to dig into this more if there's a chance we can use it as our go-to solution.
Thanks,
Steve
On Wednesday, November 21, 2018 9:52 AM, Mark Giffin wrote:
You don't lock files in git. It's a different philosophy of source control. With git the focus is on merging when there are conflicts, or using "rebase" or other methods. If you have lots of people working on the same file at the same time, you might be able to make it work in git, but you might want to just stick with something where you can lock files, like Subversion. Or refactor your files so you are not all working on the same file at once. (Many working on the same file at once does not sound like a best practice.)
I'm assuming you're using a text-based format. But if you're using something like binary FrameMaker files, you probably need to lock files.
You can't merge binary files.
On 21-Nov-18 4:26 AM, Jody Zolli wrote:
> How do you handle file locking with git, if you have multiple writers
> working simultaneously with the same book / files?
>
> -Jody
>
> On Wed, Nov 21, 2018 at 5:58 AM Robert Fekete
> <fekete77 -dot- robert -at- gmail -dot- com<mailto:fekete77 -dot- robert -at- gmail -dot- com>>
> wrote:
>
>> We have been using git for about 10 years for text-heavy docs
>> (Docbook XML and Flare HTML) with loads of binary screenshots without any issues.
>>
>> Robert
>>
>> On Wed, Nov 21, 2018 at 1:11 AM Mark Giffin <mgiffin -at- earthlink -dot- net<mailto:mgiffin -at- earthlink -dot- net>> wrote:
>>
>>> Steve, what is the source format for your docs? Is it something like
>>> binary FrameMaker files or something? Or is it text files like HTML,
>>> Markdown, DITA, DocBook, etc?
>>>
>>> If your source is text-based and you have some graphics files also,
>>> there should not be a problem with Git. I recently worked on a large
>>> set of docs in DITA with quite a few graphics, all stored in Git,
>>> and there was no problem with the binary graphics files.
>>>
>>> In my experience it's about the same with other source control
>>> programs like Subversion, Perforce, etc: doc source files in text
>>> with a few graphics files is not a big deal.
>>>
>>> But if you are using binary FrameMaker or Word files for doc source,
>>> it still might work with Git. It seems to me that any source control
>>> program is going to have the same kind of trouble with a lot of
>>> binary files. They are designed to work with text files.
>>>
>>> Mark Giffin
>>> Mark Giffin Consulting, Inc.
>>> http://www.markgiffin.com/
>>>
>>> On 20-Nov-18 3:10 PM, Janoff, Steven wrote:
>>>> Picking up on this thread from Sept.
>>>>
>>>> Tony, you'd confirmed what I'd thought about Git causing bloat.
>>>>
>>>> What I wonder about though is that Git seems to be gaining ground
>>>> in
>> the
>>> Tech Comm industry.
>>>> I'm sure it's great for API/SDK documents where there's heavy text
>>>> and
>>> few images or other binary files.
>>>> Are we just stuck with it as is, if we have lots of binary files?
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>>>> On Wednesday, September 12, 2018 6:49 AM, Tony Chung wrote:
>>>>
>>>> Git isnât recommended for binary files because its benefit of
>>>> storing
>>> changes only is negated, and bloats the repo for all users. Most FM
>>> and Word shops I know use SVN or VSS.
>>>> -Tony
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
