|
Mecurial is my favorite DVCS. I use RhodeCode for my Source Control manager, and Jenkins for my build server.
Bob Dole The internet is a great way to get on the net.
 2.0.82.7292 SP6a
|
|
|
|
|
I've used various different systems and still think svn is the best, all things considered. Some of gits merging functionality is very nice, but it still feels half baked at and times and deliberately complicated.
|
|
|
|
|
As much as I would like to disagree, I can't really. There's just too much work babysitting it. SVN is pretty much invisible, and I like it that way.
|
|
|
|
|
Yikes. Glad I don't have to use that. Subversion is bad enough and I'm supposed to start using TFS last year  .
Oh, how I long for the blissful (*) days of CMS[^].
* Well, no, we weren't writing in BLISS.
|
|
|
|
|
Learning curve: Two miles through the snow, uphill, both ways.
But then: enlightment.
I was lucky, had someone to hold my hand, still took me some weeks of daily use to get used to it.
It is a pinnacle of "developers aren't users" software, so yeah, I see you pain. Yet I do not want to miss the workflow anymore I can have with git. All attempts to plaster a decent UI on top of it somehow make it worse, though.
|
|
|
|
|
peterchen wrote: I was lucky, had someone to hold my hand,
Fortunately, I do to, but I work at home and my client works at home, and we don't live in the same home, so often enough I have to figure things out on my own. Worse thing is, I thought I had it under control, but then discovered something yesterday that I couldn't work around.
My solution? Deleted the whole project and re-cloned it from the remote. Maybe that's what I'll just do as s.o.p, hahaha.
Marc
|
|
|
|
|
Good news Marc, there is help[^]. 
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Nagy Vilmos wrote: Good news Marc, there is help[^].
In my case, no, because it's a Ruby on Rails app, and I'm using RubyMine as the editor (pretty slick product) but it's figuring out RM's support of Git without first understanding how to use Git from the command line is not a good idea. Once I get the command line stuff under my belt, then I can poke around RM's GUI support and see what it's doing (it has a nice display of what it's telling Git to do.)
Marc
|
|
|
|
|
|
|
I now work with a guy who is completely confused about how to use SVN...Constantly complaining about how someone else used to manage making commits for his source code. 
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
S Douglas wrote: Constantly complaining about how someone else used to manage making commits for his source code.
Wow. How dificult is right-click on a folder and select Commit? Well, if you're using Tortoise SVN.
Marc
|
|
|
|
|
Marc Clifton wrote: if you're using Tortoise SVN.
Yea, we are and it is that easy...
I am beginning to believe he just wants something to complain about.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
It was created to solve a specific task in a specific context.
And then everyone wanted to use it for everything and rationalized the usage due to the perceived acceptance.
|
|
|
|
|
*cough* SmartGit[^] *cough*
modified 13-Feb-19 21:02pm.
|
|
|
|
|
Amrykid wrote: *cough* SmartGit[^] *cough*
OK, that looks really useful. Much appreciated!!!
Marc
|
|
|
|
|
Amrykid wrote: *cough* SmartGit[^] *cough*
By the way, I want to thank you for pointing out SmartGit - that has made life a LOT easier, and my client is very impressed with the application as well!
Marc
|
|
|
|
|
No problem, I've been using it for years and I just wanted to share such a wonderful application. 
modified 13-Feb-19 21:02pm.
|
|
|
|
|
Git and SVN solve different problems. You should use the one most suited to your current project/needs. SVN is a centralized whereas Git is a distributed. With SVN, you have a local working copy and with Git you have a local repository. It is for this reason it may seem that Git is overly complex. If you want to fork a repo and add features that will be different from the projects original goals then Git might just work best for you. If you want a group of individuals contributing to a common code base then SVN will be your best bet.
|
|
|
|
|
I strongly disagree with you guys.
I have working with Git and SVN for quite a while - in different environments and at different companies, and I prefer Git to SVN.
At the end of the day - I found that Git is much stronger and you are able to do so much more with it that thing SVN. Yes sure to get to all the nice interesting stuff it takes some understanding - but if you think about it development is the same. If you think you will become a developer with only a bit of understanding of general concepts you are wrong. <-- this is especially to all the Graphic Designer who this that they are developers thanks to WordPress and Drupal 
Git is not all that complex and the features (pros) out way the learning curve (cons) I would say.
I am not saying that there is something wrong with SVN or that Git is better - it different and its all dependent on what you want to do, and how much you are willing to learn.
This is quite a good blog regarding Git and SVN:[why is git better than subversion]<-- don't judge the blog by the title
In the defense of git:[10 things i love about git]
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live."
|
|
|
|
|
The problem with Git is that Linus has been quoted in saying something along the lines of "Git isn't a tool [solution], it's a framework." This lead me to believe that you should really have a few scripts set up that do the heavy-lifting for you. SVN is a tool, it does what it is designed for and nothing more: by using SVN you subscribe the workflow imposed by the SVN developers and have no versatility, where Git can be jimmied into basically any workflow.
GitHub for Windows also gets rid of a lot of the pain (really, one-click pushing and pulling) - and it isn't only for GitHub repositories[^]. In a similar light, Microsoft have released the GitHub integration for Visual Studio and I assume it will be of the same caliber (read: simplicity) as TFS.
I only drop to the CLI when I really need to these days, and haven't needed to in a couple of months: the Windows tooling is great for it, if you know it's there.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
The biggest potential problem with version control is when people don't use it frequently. People won't use frequently what isn't easy to understand and use. For that reason, if for no other, Subversion >> GIT.
If you're working on your own, or within a team where every single member understands how and loves to use GIT, then all the power to you. But if you have only one member in your team that isn't comfortable with it, you're going to have problems, sooner or later.
|
|
|
|
|
So I'm not alone - thanks for making me feel better about that!
Overall I find most source control a pain (and worry), when they should make life easier. Maybe it's a lack of trust on my part, but I still do a time stamped batch file backup of the source irrespective of using a source control (not GIT!)
As for GIT, I just find it too complicated - which means it has a low trust rating in my book, if you can't easily understand a system how can you trust it? As one of our engineers said it must have been named after the characteristics of one (or all) of its designers!
|
|
|
|
|
Source Control? We don't need stinkin' source control... 
Seriously, it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
|
|
|
|
|
RafagaX wrote: it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
Yes, I would agree. I can see where my idea of working with revision control is different. I rarely would branch my SVN tree, and the idea of keeping local a local repository with all of the local branches and changes on my computer (until they are pushed onto the remote repository) I can see as possibly beneficial but overly complex, and frankly, scares me a bit with regards to losing my work due to a disk failure or the complexity of merging my work if I fall too far behind everyone else's branches.
However, having read something recently, I am beginning to change the mental picture I have been holding - namely, that there is also a local repository as well as a remote repository. That helps me understand why a commit doesn't actually get seen on the remote server until a push happens.
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
