There's a version of LibreOffice version for Windows too. And, it's aligned with the Windows user's intuition of the SETUP.EXE installation procedure. So, it should not be too hard to switch.
@prashere @arunisaac that's exactly the problem. It is difficult to convince people to switch, specially when you are in the middle of some work where your primary concern is your content, not the tools. ...
@moaz786 I am not particularly pro-LibreOffice. I prefer doing my writing in !orgmode . But LibreOffice is the best I can do when collaborating with those who don't like plain text.
@nds Plain text and markdown is ok. But, I don't know if git is suitable and easy enough for a writer. Even for a programmer, git can be a little difficult. Are there any writer-friendly version control systems? @lohang You are a writer, right? What do you think?
@arunisaac @nds I haven't looked into this. I am able to use #git - looking at various notes and guides I have saved - but I haven't been able to use it for anything serious because my collaborators don't have time to learn it. Besides, if we are to use it for a project like this, we have to host it somewhere and this costs lot of money. Cannot put what we write out in the open on github.
I maintain my blog, and other writing projects in git repos. And, most of the time, I can't think of meaningful commit messages. I don't know, maybe, writing needs a different kind of version control system.
@prashere @arunisaac @nds yes, we *can* use it to a certain extent. But how to incorporate all these aspects?: This is a book, co-translated by two people, edited by another. Documents have to be distributed and redistributed among each other and edited. If we are using a wiki, we have to work online, on the wiki all the time, or work offline for a while, copy-paste and publish one version while the others edit/improve online. Sometimes there seem to be three versions of the same text. How to manage this?
@prashere @arunisaac @nds LibreOffice seems to be the most sensible solution to me. #Git is capable of handling all these aspects of the process, but too complicated and expensive to implement.
@prashere @arunisaac @nds having three versions of the same text is an unnecessary complication we have created. We should make it two, and add some common sense, combine it with LibreOffice :-D
Yes, I pretty much self host everything. I run cgit (https://git.systemreboot.net/). But, I haven't collaborated much with my git repos.
You don't really need a git web frontend to collaborate. You can mail patches made with `git format-patch'. But, for writing, I guess that would be clumsy. But, more generally, I think everything in git is clumsy for writing.
There is GNU RCS. Apparently, it's a very simple VCS. I haven't tried it, but maybe it would be better than git for writing.
@arunisaac I just checked GNU RCS docs. It claims to be "useful for files that are revised frequently, e.g. programs, documentation, graphics, and papers."
Sadly, that too doesn't seem to have a graphical user interface.
@lohang while I now agree that git is not the technology for you, I'll note that git doesn't have to be run on a paid instance with a fancy webui. It can work anywhere with a posix file system and ssh
@arunisaac aha! That looks very interesting indeed! I am going to give it a try sometime soon. This conversation prompted me to read more about git and version control too. Thanks for all the helpful pointers.
If #git isn't the right version-control system for your work, there are others that may or may not fit your needs. Look at #hg (mercurial), #bzr (bazaar), #fossil, #darcs, or #svn (subversion). I know svn has a gui tool available for Windows. Not sure what kind of gui tools the others may offer.
@lnxw48a1 Isn't #bzr dead? I remember there being much to do on the emacs mailing list about how bazaar was as good as dead and there's no reason to be forcing it as the emacs version control just because it's a GNU project. Like, it getting to the point of RMS having to email the developer every few months to remind him to work on important bugs.
@tekk to continue with tradeoffs, you need to bear in mind when considering #darcs that their merge algorithm will occasionally bump into exponential (that is, 2^n) cases. Projects often dismiss it based on performance because of it.
@lnxw48a1 Thanks! I'm slowly going through the alternatives you suggested. On one hand I have this ongoing project which involves Windows/MS Word users. They are very unlikely to learn something like #git and command line even if it can be used without it being hosted somewhere online.
On the other hand I would like to have some version control system that I can run locally to manage what I write and translate. Not necessarily collaborative work.