Re: [docbook] XML/XSL Revision Control/ Source Code Versioning: Ideas, Methods, Tools for Specific scenario as a Content Writer?

[Thomas Schraitle <tom_schr@web.de>]

Hi AS,

Am Samstag, 8. Dezember 2012, 15:51:05 schrieb AS:
> [...]
> 
> I'd like to do Source Code Versioning/ Revision Control for them and
> wondering what you guys do for the same?

Yes, always. Don't use no version control system (VCS), it's not worth the 
hassle. 


> [...]
> At the moment I can think of manually copying and renaming each version of
> the XML everytime, but its kind of cumbersome.

Hmn. This seems unnecessary to me. This is usually something where version 
control systems are used for. Either create a separate branch or a tag. DON'T 
copy your data just for the sake of having a new version. 


> I've also used some Source Code/ Revision Control in the past but its too
> far ago.

I guess you should take the time and update your knowledge. A lot of (good) 
things happend.


> QUESTIONS:
> - What do you use and how?

Well, generally speaking any version control system will do. ANY VCS is better 
than nothing. If you get used to it, you won't miss it anymore.

Currently, most of the time I use Subversion but have worked with Mercurial 
and Git too. The methods are mostly the same and differ in some minor details.

I (have to) use Subversion for years now as our documentation are stored on a 
SVN server. It does its job well and it's easy to use. 

For my private little project(s) I use Mercurial for some time now. It's just 
that I wanted to try some distributed VC system. It's similar to Subversion, 
so the "mental migration" was a lot easier than with Git. 

Some weeks ago, I participated in another documentation project, but they use 
Git. For me, Git has LOTS of features, but I'm not sure if I ever will be able 
to grasp all the little details. It seems, Git is incompatible with my brain. 
;)

As I said before, all versioning systems use the basic method: store your data 
in a repository and commit changes regularly. All systems can be used for your 
documentation, at least if you commit text files instead of binary files. Of 
course, you can commit binary files too, but in that case you can't use all 
the advantages of a VC like diffing and merging.


> - What do you suggest using in my SPECIFIC SCENARIOs? and how?

Actually, I don't know. All VCS has their advantages and disadvantages so it's 
hard to tell which is "the best" for you. Basically, it's a matter of taste. 
All will do their job.

For me, Git is overly complex and is probably a bit too much for just using it 
for documentation. It's made for Kernel(!) development with lots of developers 
and lots of branches and merging actions. For their development model, Git is 
perfectly fine. For a (simple) documentation project, it's a bit too much. But 
that's just my opinion, others will see it differently.

As I used Subversion for years, the path to Mercurial was pretty easy. So I 
prefer Mercurial over Git.

To summarize it, I guess, you should update your knowledge about VCS and read 
articles about all the three. You can try them out which one do you like most. 
All will work for you, but it depends on how comfortable you are with such a 
tool. Remeber, you have to work *all* the time with the tool. You should know 
the basic things, otherwise you will hate it. :) 

Another approach is to start with Subversion. Install it, configure it, use 
it, and get used to it.
If you miss some features which Subversion don't have, you can think to 
migrate your repository to Mercurial or Git. They have conversion tools for 
this task and most of the time they work.


Hope that makes sense. :)


-- 
Gruß/Regards
  Thomas Schraitle