-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
Tortoise SVN
- Thread starter Train
- Start date
sourceninja
Diamond Member
You could just use svn on the command line....
meh
It's not on auto update. But will give me popups every day (maybe twice a day depending on usage?) alerting me that I am "out of date" until I update.
Hey, I'm as big a fan of the command line as the next guy. Personally, I use Git. But I'd give my eye teeth (metaphorically) for a really good Git GUI.
IMHO, version control isn't suited well to the command line. There are too many different options and operations to remember.
Hm, can you block the update server in your hosts file?
I'm not one to shy away from a command line either. But typically the guys who are ok with using the command line are just committing/updating, essentially reducing version control to a backup system. IMO, if you are using it the way it SHOULD be used, you need a GUI. I enter detailed comments (SPELL CHECK!), and I don't commit all changes as one commit. I break them out on a per task, or per issue, basis, so that any one can be rolled back independently. The checkbox list tortoise offers is indespensible. I'm an svn Nazi at work, if someone just commits a whole days worth of work as a single commit, I flip out. VC is not a "save your work once a day" tool, it is a VERSION control tool.
not a bad idea, but then I'd NEVER update.
Last edited:
sourceninja
Diamond Member
My entire office uses git, we only use command line. We have very detailed commit logs and use tons of the features git offers.
For example, my daily work on a new feature might be as follows.
1) Clone source material
2) Create feature branch
3) Begin working on feature
4) Commit as needed and make tags at milestones
5) Squash commits into logical commits to be merged back into master
6) Get QA to checkout master from me.
7) Get approval from QA to push changes back to Origin.
8) Resolve any merge issues (typically none).
What is it with the odd attraction to the command line? Anyone who seriously thinks they can update from a repo using the command line faster/easier than I can do it using Tortoise from explorer is just biased, imo.
As for updates... yeah. But isn't this just a general "feature" of open source? You see the same thing with FileZilla, Virtual Box, FireFox, etc.
As for updates... yeah. But isn't this just a general "feature" of open source? You see the same thing with FileZilla, Virtual Box, FireFox, etc.
GodlessAstronomer
Lifer
TortoiseHg is the same, too many damn updates. I use the GUI client because there is a fancy version that interfaces with Kiln so the command line doesn't have the functionality I use for work (or it's more difficult). For SVN I just use the command line.
GodlessAstronomer
Lifer
It's a programmer thing. Some insecure programmers think that it makes them more of "a man" if they do everything in the command line, regardless of whether it actually is more efficient. It's really annoying.
sourceninja
Diamond Member
No it's the fact that it's usually easier to do complex things on the command line. Skilled computer professionals typically want to do everything as automated and quickly as possible. The command line is the best known way to accomplish that.
Woosta
Platinum Member
Truth. Same thing as text editing for me, in which case I don't use any crappy GUI but instead vim.
There's no way a blanket statement like that can be true. Right-click a repo in Explorer, click Update. You're telling me that doing the same thing via the command line is just as easy? See, the thing is that there is a certain kind of skilled computer professional who thinks that GUIs evolved just to accommodate the growing number of idiots who use computers. I guess Alan Kay anticipated all those idiots in his work at PARC nearly 40 years ago.
The fact is, that for most complex tasks, if there is a well-designed and mature GUI interface for the operation, it is easier to use than to execute the same command from a shell.
sourceninja
Diamond Member
How do you get to the folder? Multiple right clicks, taking your hands off the keyboard to another device, and being unable to save the command for later. Can you pull changes from the server, create a dev branch, and open the project in a single action?
I seriously don't know any professionals that use the gui of their operating system for anything more than window management and very basic file management. For example, yesterday I was tasked with finding all word docs submitted by staff members on our file server, identifying files that were more than 2 years old, categorizing them into folders by department (they are in a giant drop box type folder, this was the hardest part but was simply solved with a pipe and a script), encoding them into pdf files, and finally generating a spreadsheet report for upper management.
Do that with a GUI quickly. It took me about 2 minutes to solve.
The cases were a gui is faster are usually very simple operations or task where you just can't be bothered to learn the tool your using.
I seriously don't know any professionals that use the gui of their operating system for anything more than window management and very basic file management. For example, yesterday I was tasked with finding all word docs submitted by staff members on our file server, identifying files that were more than 2 years old, categorizing them into folders by department (they are in a giant drop box type folder, this was the hardest part but was simply solved with a pipe and a script), encoding them into pdf files, and finally generating a spreadsheet report for upper management.
Do that with a GUI quickly. It took me about 2 minutes to solve.
The cases were a gui is faster are usually very simple operations or task where you just can't be bothered to learn the tool your using.
Yeah, well a lot of the things we're debating fall into that category of simple file management, like updating from a repo. You can always find examples like the one you posted, i.e. one-off tasks for which there is no simple GUI interface. That doesn't mean that it's always faster to use the command line.
In your specific example I would agree, scripting it would be easier (though I cant even think of a way to do what you said using any known gui app, so its really the only option)
When it comes to subversion... Lets say I have 4 bugs to fix. I fix each of them. I go to commit my changes, Tortoise shows 20 files have been modified. Hmm, which ones were for bug #1, which for bug #2, etc. Some may be obvious, others not so much. I can double click on the qustionable ones and instantly see the diff's highlighted.
These 20 files are spread across multiple sub directories in my local repo. I need to check 5 files for bug 1, add a comment, and commit, then check 3 files for bug 2, add a comment, committ, etc.
With Tortoise this is as simple as checking a few check boxes, typing a comment, and hitting Ctrl-Enter while may hands are still in two-hand-typing mode. I really can't see how this can be done in the same amount of time using command line SVN.
keep in mind some of the paths off the root can look like:
src/plugins/CustomReporting/ExpenseCategories/DataModel/ExpenseCategoryEntity.cs
which may need to be committed along with two other files with equally long, but different, paths
GUI's are about automation. I use subversion A LOT, I am perpetually updating, comitting, diffing, adding hooks, adding rules, ignores, reverting, tagging, branching, merging. A GUI to automate these tasks makes perfect sense.
Now if I were to be doing your example task... finding docs that meet a certain criteria, sorting them, converting them, etc .... on a regular basis, I would build a GUI to quickly interface with my script.
Last edited:
sourceninja
Diamond Member
That's what tab completion is for.
Honestly, I don't use svn, I use git, but I can't say I've ever had a commit not take more than a few seconds to type and execute no matter how many files. I recently tried Tower, a very nice git gui application. It was such a pain to have to find the files I wanted to add, then commit them, then push them.
I don't usually have that use case you described because I'm a branch fiend. Usually I have one string that is just git commit -am "message" for the branch changes and I make a branch for any piece of work that needs to be commit by itself. Then I just merge the branch into master and push it in another single command (sometimes squashing the commits into simpler commits to remove cruft or re-writing commit messages to contain more detail).
Tower seemed so much easier and it is a great application, but I lasted all of a week before heading back to my terminal. It's where I can automate tasks as I see fit and work smarter. The only GUI application I really can't live without is QuickSilver, which I guess is really a gui app that let's me use text to manage most of my gui apps (kinda like a magic smart terminal). I've even moved back to vi. I had moved to textmate, then coda, but ultimately I found my work slowed down by their inability to provide what vi and emacs can provide.
One of my co-workers did point out that we do have a person in our department who is all gui oriented. She is constantly forgetting commits because the icons don't always update when she makes a change. She also routinely requires our help doing any kind of complex merging (like a 3 or 5 way merge) as the GUI seems to handle that like shit. Unrelated (possibly) she is also the only windows user on our team and has very little Unix experience.
Honestly, I don't use svn, I use git, but I can't say I've ever had a commit not take more than a few seconds to type and execute no matter how many files. I recently tried Tower, a very nice git gui application. It was such a pain to have to find the files I wanted to add, then commit them, then push them.
I don't usually have that use case you described because I'm a branch fiend. Usually I have one string that is just git commit -am "message" for the branch changes and I make a branch for any piece of work that needs to be commit by itself. Then I just merge the branch into master and push it in another single command (sometimes squashing the commits into simpler commits to remove cruft or re-writing commit messages to contain more detail).
Tower seemed so much easier and it is a great application, but I lasted all of a week before heading back to my terminal. It's where I can automate tasks as I see fit and work smarter. The only GUI application I really can't live without is QuickSilver, which I guess is really a gui app that let's me use text to manage most of my gui apps (kinda like a magic smart terminal). I've even moved back to vi. I had moved to textmate, then coda, but ultimately I found my work slowed down by their inability to provide what vi and emacs can provide.
One of my co-workers did point out that we do have a person in our department who is all gui oriented. She is constantly forgetting commits because the icons don't always update when she makes a change. She also routinely requires our help doing any kind of complex merging (like a 3 or 5 way merge) as the GUI seems to handle that like shit. Unrelated (possibly) she is also the only windows user on our team and has very little Unix experience.
tab completion is supposed to be as quick as a check box?
and does your command line underline mispelled words?
Git guys don't use the GUI because there still isnt a decent gui made for Git. Once a Git gui comes along that is as handy as Tortoise you guys will be on it like flies on shit.
and does your command line underline mispelled words?
Git guys don't use the GUI because there still isnt a decent gui made for Git. Once a Git gui comes along that is as handy as Tortoise you guys will be on it like flies on shit.
tatteredpotato
Diamond Member
I can see both sides of the debate. I've used both command line and GUI versions of SVN and for most of the time I use the command line. You can configure the command line to pop up whatever editor you want to type in a commit message, so the spellcheck argument is kinda moot.
The advantage of CLI is you learn one interface for all platforms, but a GUI will be different on every platform (I'm not aware of any cross platform GUI front-ends for SVN).
The advantage of CLI is you learn one interface for all platforms, but a GUI will be different on every platform (I'm not aware of any cross platform GUI front-ends for SVN).
sourceninja
Diamond Member
You realize there is a tortoise for got right? Also I used svn for years and I hate tortoise.
Somehow I don't see launching a GUI to assist the command line as more efficient than just using a GUI in the first place.
sourceninja
Diamond Member
Actually, for a long time I did do just that. I had textmate my default editor. So if I did type git commit it would pop up textmate for my commit message. All of the efficiency of the command line AND a nice text editor all without touching a mouse. When I was done, just a cmd-s and cmd-q.
Ultimately I went back to vi. Also, I mentioned that I did not like tortoise not because it was obvious, but because it was implied that if any command line users tried it then would never go back.
I went years without learning a solid command line focus. I didn't make the switch until it was forced on me with headless servers. I have tried to use may gui systems that I've been told make my life easier. I've found all of them lacking.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
