Should Version Control Softwares be used from Command Line or GUI

Question

I was going through some tutorials on TortoiseHg. Despite having a rich GUI, the first examples are given using command line options. Does the ideal usage involve command line or it was started that way so one has idea of what is happening under the hood and GUI internally uses this command anyway.

Answer 1

Use what you want. Use what makes sense for what you are doing now.

While I'm mostly a command line guy (I use the GUI only to get a graphical representation of revision graph), I've trouble to understand why you think using the command line gives you a better understanding of what happens behind the hood (well excepted for GIT :)), usually there is a clear mapping between the two even if CL may give you access to some little used features.

Now in my opinion, automating what can be automated in the process is part of the job and for that, CL is mandatory.

Answer 2

It's easier to write tutorials using the CLI. All you need is text! Trying to demonstrate workflows in a GUI means screenshots, and circles and arrows and a paragraph on the back of each one explaining what each one is.

Use whichever you want. There is no "right" way.

Answer 3

I prefer a mix of both.

The GUI is fine for day-to-day use of the core functionality.

However, it is very useful to know how things work "behind the scenes" on the command line -- especially if you want to make use of more advanced features, or write scripts to automate some common tasks.

Answer 4

Ideally, you'd want both.

Generally, the commands are implemented as a command line, which means that you have the following benefits:

1. You can put any number of GUIs on top.
2. You can integrate it with whichever tool you like.
3. You can use it in scripts.

The latter is extremely important. Want your build server to checkout your code, and it doesn't have a direct API to the system? Well, with a command line interface, it will be able to work. The same applies to everything.

Answer 5

It started as a command line. Look at svn, bzr, hg, git... Some needed GUI, because they were to lazy to remember commands and wanted buttons there fore most of existing GUI's are juts overlay for command-line interface, although there are some such systems that are GUI only (those are usually unseen and are implemented in some text editors).

Sure both are needed. In windows its bit hardcore to use cmd to make commits and use VCS while in Linux i personally use command-line mercurial every time since i get things done faster and cleaner.

Where it should be used from (GUI vs command-line)? You got the choice. Learn both (you'll need it) and then use the better one in your personal opinion.

More on topic: http://en.wikipedia.org/wiki/Revision_control

Answer 6

Whatever works for you. I have seen GUI masters that are so fast it puts a lot of command line users to shame and vise-versa. The only thing that matters is choosing something and learning the ins and outs of it. Once you're very good what you chose, learn the other way.

Answer 7

I think it is the general answer for types of software people use regularly: Initially GUI and once someone has mastered the concepts, then more and more command line. I am currently using a specific version control tool in a once per month basis. It would be impossible for me to remember any command line syntax. So only GUI.

On the other hands after some months of using subversion, it became a command line only affair, no need for visuals.

Answer 8

TortoiseSVN for SVN on Win32/64, because of the icon overlays for visual feedback.

Otherwise: GUI for less-frequent operations (superior discoverability & better affordances), command-line for most common operations (increased parsimony, fewer keystrokes).

Answer 9

You'll see that most answers, refer to use both. Learn to use both, and use each method acording to the situation.

The G.U.I., is usually more easy to use, but, there are scenarios, wheter you have to stick to the command line version. Some programming I.D.E. include or can be extended with a G.U.I. for the C.V.S. of your choice.

Sometimes, you may need to use a C.V.S. for files that aren't applications, or aren't supported by your programming I.D.E.

I worked once, in a VB6 project where the VB6 I.D.E. included it own C.V.S. included with its G.U.I., unfortunately it didn't work well, and sometimes, corrupted files, or lost some versions. We had to install an Open Source C.V.S., that we had to use from the command line.

Answer 10

Use whatever makes you most productive, but learn the CLI regardless. It's the lingua franca of the VCS, so you'll need to know it to ask and/or answer questions on places like stack overflow. Also, the most advanced features are only available on CLI, so chances are you will eventually end up wanting it, even if only rarely. You can also mix and match clients. I personally am most productive using a GUI for history visualization and manually resolving merges, and the CLI for everything else.

Answer 11

If you have a lot of repeated operations, such as adding some but not all files

git add file1
git add file2
git add file3
...
git add fileN

then GUI with checkboxes is definitely better.

If you need to enter hashes as command arguments, then GUI is definitely better (allow to select and no need to remember the hashes)

Answer 12

The GUI is mandatory when you have any tool deployed to a large set of users.
If that tool has some multi-step operations (workspace creation, multiple files merge, ...), a wizard dialog is welcome.
If that tool can present a graphic representation of some state (history, version tree, branches and merges, ...), a user will appreciate a graphic window instead of a wall of text in a shell.

But a CLI is also mandatory every time any GUI operation fails: the same operation done from a CLI often generate an error message much more precise and complete than the error dialog box displayed by the GUI.
And any scripting can use of course a CLI for automation purpose.