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:Lin Laurie <linlaurie1 -at- hotmail -dot- com> To:"Janoff, Steven" <Steven -dot- Janoff -at- hologic -dot- com>, Mark Giffin <mgiffin -at- earthlink -dot- net>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 21 Nov 2018 22:35:59 +0000
I happen to be working on an article about Git and GitHub right now. Definitely if you are managing text files, Git is a good tool. It can track the change history, restore previous versions, and more. When using larger files, you can add on an extension for larger files called Git Large File Storage. It replaces large files with text pointers inside Git, while storing the file contents on a remote server like GitHub.Com or GitHub Enterprise. But the tracking of binary files like Word, FrameMaker, video, or others is what causes the repositories to blow up and also makes your commits impossible to read.
All of this also means that if you switch branches, it slows that process down significantly.
I found some good resources by googling "git binary files best practices"
My preference would be to find an alternative if I were working with MadCap, Word, or other authoring tools that involved lots of binary files.
Regards,
Lin Laurie
www.linlaurie.com
-----Original Message-----
From: techwr-l-bounces+linlaurie1=hotmail -dot- com -at- lists -dot- techwr-l -dot- com <techwr-l-bounces+linlaurie1=hotmail -dot- com -at- lists -dot- techwr-l -dot- com> On Behalf Of Janoff, Steven
Sent: Wednesday, November 21, 2018 11:04 AM
To: Mark Giffin <mgiffin -at- earthlink -dot- net>; techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: Git for Tech Pubs [was FW: L@@king for recommendations for a doc source-file management system....]
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>
> 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> 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
Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
