Question What version control system do you use in add-on development?

[orb]

Sorry, Face, but I fail to see how discussing SCs can be an off-topic in the topic that discusses SCs

You are discussing why TFS is better than any other VCS, which isn't the topic of this thread.

 

[agentgonzo]

Would it make sense to start a blog series about why and how I'm using DVCS to develop add-ons, or would that just be a waste of time because everybody is happy with the way it is, anyway?

I think this is a very good idea. Target it at people who don't know what a VCS is or don't use one.

I found that my own private development changed dramatically when I started using VCS. Even on my own private system where I was the only user it was of immense help and provided a really good safety-net for the "Damn, how did I get that to work a week ago" and "Oh my God, I wish I hadn't removed that stuff the other day, I could really use it now" scenarios. Even the situation of "I want to x this to see whether it's better than my current method" is greatly improved with the ability to just issue a revert, rather than "zip up a backup, change, realise it's not for the better, try to find old zip file, copy back over" method that you have to use without VCS.

Using VCS makes development EASIER, rather than harder. Teaching new users about it is a very good thing to be doing and will ensure you brownies points with the Gods of software development.

 

[MeDiCS]

"Damn, how did I get that to work a week ago" and "Oh my God, I wish I hadn't removed that stuff the other day, I could really use it now" scenarios. Even the situation of "I want to x this to see whether it's better than my current method"

For beginners, showing how VCSs may improve their current situation is, IMHO, always better than preaching based on hypothetical, contrieved, uncommon, or textbook situations. These three scenarios are excellent examples, which, I guess, anyone who coded anything but the most trivial program has encountered.

In other words, branching and merging are extremely useful, immutable tags are a must, centralized and distributed VCS are almost two different worlds, but most of these concepts matters little to those who have no idea of what a VCS is in the first place.

 

[Ripley]

I really appreciate Face's offer and effort to explain what's this all about, but please keep it with simple words.
Don't misunderstand me Face, I admire your vast technical knowledge (yours, and that of many other OF members), it is light years ahead of us "average common users". That knowledge can lead you to imply some terms or concepts. Don't forget who is your target audience.
Thanks for reading.

 

[Face]

So let's try this: http://www.orbiter-forum.com/blog.php?b=1158

 

[Artlav]

Face, does Mercurial spam directories?
I.e. CVS/SVN put special directories into EVERY directory of a project, making a terrible mess, while GIT only puts one special directory at the root of the project.
What does Mercurial do?

 

[orb]

Mercurial puts .hg only in the root directory of the project.

I.e. CVS/SVN put special directories into EVERY directory of a project

Subversion puts .svn only in the root directory of the project in the latest versions (at least in working copy of the project).

 

[Artlav]

Ah, nice.
So they all solved that problem.

 

[kuddel]

Mercurial puts .hg only in the root directory of the project.[...]Subversion puts .svn only in the root directory of the project in the latest versions (at least in working copy of the project).

While we are on this topic: Do you know if Mercurial might need some other 'hidden' files? I remember that git has those ugly .gitignore files flying around everywhere in the working-copy.
It might not be true anymore for more recent versions of GIT, but out of curiosity I would like to hear from real users obout the 'features'

-----------+----------------+-----------------
 VC-System | .xxx folder(s) | .hidden files(s)
-----------+----------------+-----------------
           | one '.svn' in  | none
Subversion | working-copy   |
           | root directory |
-----------+----------------+-----------------
           | ???            |
GIT        |                |
           |                |
-----------+----------------+-----------------
           | one '.hg' in   |
Mercurial  | working-copy   |
           | root directory |

This table is of course only true for current version (of SVN)

I would like to see this table filled by an actual GiT/Mercurial user.

Thanks,
kuddel

 

[agentgonzo]

I've added in Git (why do people always put git in full capitals as if it's an acronym?)

VC_System | .xxx folder(s) | .hidden file(s)
Subversion | one '.svn' in working-copy root directory | none
Git | One '.git' directory in root directory | optional .gitignore or .gitkeep (probably more) at any level
Mercurial | one '.hg' in working-copy root diretory |

 

[orb]

There can be .hgignore in the root in Mercurial.

EDIT: Mercurial: Tag Design: Working directory pollution

 

[MeDiCS]

I've added in Git (why do people always put git in full capitals as if it's an acronym?)

VC_System | .xxx folder(s) | .hidden file(s)
Subversion | one '.svn' in working-copy root directory | none
Git | One '.git' directory in root directory | optional .gitignore or .gitkeep (probably more) at any level
Mercurial | one '.hg' in working-copy root diretory |

Git also uses .gitattributes and .gitmodules.

While we are on this topic: Do you know if Mercurial might need some other 'hidden' files? I remember that git has those ugly .gitignore files flying around everywhere in the working-copy.
It might not be true anymore for more recent versions of GIT

.gitignore files were always optional. Ignored files can also be specified in .git/info/exclude (or something like that).

 

[Face]

Git also uses .gitattributes and .gitmodules.


.gitignore files were always optional. Ignored files can also be specified in .git/info/exclude (or something like that).

Indeed, so does Mercurial with equivalent .hgxxx or .hg/xxx . May I ask what the point of your question is here, kuddel?

The use of the word "ugly" implies that you see it as some kind of disadvantage. As it is optional, I wouldn't say that it is so...

 

[asmi]

The use of the word "ugly" implies that you see it as some kind of disadvantage. As it is optional, I wouldn't say that it is so...

I can only say that some _other_ SC doesn't pollute working directories

 

[Face]

I can only say that some _other_ SC doesn't pollute working directories

So you think we should go back to where we discuss why X is better than Y because of Z? *sigh*

I don't think that kuddel was just searching for arguments for this kind of debates...

 

[asmi]

So you think we should go back to where we discuss why X is better than Y because of Z? *sigh*

I don't think that kuddel was just searching for arguments for this kind of debates...

I still don't agree with your definition of what's off-topic and what is not, but I'm not gonna argue with you here on that. I just think that once "use-not use" question is resolved, "use what" question pops out immediately.

 

[kuddel]

May I ask what the point of your question is here, kuddel?

The use of the word "ugly" implies that you see it as some kind of disadvantage. As it is optional, I wouldn't say that it is so...

You may ask. Supposed it's not rated off-topic
I just love to have my working copies only contain "project files" and as few "RCS optionals" as possible.
Not that it *really* matters, but I fell over those .hidden files/folders in many RCS-Systems in the past and I really loved when Subversion changed it's policy to only use one .svn folder some time ago.
Again, this is just my opinion.

Nevertheless this thread has given me more summarized information about the different RCS-Systems than I could gather anywhere else.

Thanks all,
Kuddel

 

[Urwumpe]

I think we should limit the thread to "Version control software that you use at home". Otherwise we are soon talking about HP ALM.

 

[Face]

You may ask. Supposed it's not rated off-topic
I just love to have my working copies only contain "project files" and as few "RCS optionals" as possible.
Not that it *really* matters, but I fell over those .hidden files/folders in many RCS-Systems in the past and I really loved when Subversion changed it's policy to only use one .svn folder some time ago.
Again, this is just my opinion.

Nevertheless this thread has given me more summarized information about the different RCS-Systems than I could gather anywhere else.

Thanks all,
Kuddel

Thanks for the answer. I know that the .svn folders were annoying, because more often than not it confused me in "grep" situations.

But that was for most parts not due to the .svn folders per se, but because of the way SVN stored information about the working copy back then. It simply produced a second copy of the currently checked-out files in those hidden folders, and naturally these copies make file system operations stumble. That and having them in every sub-folder mandatory produced the problem that most know as "working-copy pollution". CVS was not too different.

In most systems today (SVN included) the only mandatory pollution is the .xxx folder in the root of the working copy.

About the off-topic: I know that whenever the term version control is brought up, there is an urge in people to explain why the system they use (and love) is better than all other systems. But instead of explaining why they love working with their system, they explain why they hate working with the system of somebody else. This is a natural behavior, it seems. You can see it in the insider joke "vi vs. emacs".

My point is: such discussions serve no purpose besides having a flame-war. It would be similar to the OS war thread. If you really have to discuss this, please make such a thread. But do not turn this poll into it.

regards,
Face

 

[NukeET]

Many thanks for the feedback.

As I can see, the majority of developers (at least those active here on the forums) either use Subversion (in a more or less "private" environment) or no version control at all (because they don't know what it is to start with).

Would it make sense to start a blog series about why and how I'm using DVCS to develop add-ons, or would that just be a waste of time because everybody is happy with the way it is, anyway?

I don't think it would be a waste of time. I read the history of Git's development, and decided to try that one first to see if it fits my needs. Further input from you on the use of DVCS would expand the overall knowledge of everyone involved with Orbiter.