SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 36

Thread: Version Control

  1. #1
    SitePoint Addict stu567blue's Avatar
    Join Date
    Aug 2007
    Posts
    316
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Version Control

    Hi All,

    It's been a long time since I last posted on here.

    Quick question, I am thinking about using some kind of Version Control / Source Control for my online store. However I am not entirely sure how they work. I have a linux VPS server which uses CentOS and cPanel. Has anyone else had any experience of setting up source control?? What was your thoughts?? How did it help you with your web projects??

    Any help would be great.

    Thanks

  2. #2
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    I've used SVN for years after losing an entire project due to working late and running a rogue command that wiped it out.

    Most hosting services can setup SVN through a control panel and you can then use TortoiseSVN or something similar to interact with it locally. The basics of source control are you import your current set of files, then you checkout your repository so you can work locally, and as you make milestones/changes you commit them back to the repository.

    Here is a good read and a few of their examples are using SVN:
    http://betterexplained.com/articles/...rsion-control/

  3. #3
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    I've used SVN for years after losing an entire project due to working late and running a rogue command that wiped it out.

    Most hosting services can setup SVN through a control panel and you can then use TortoiseSVN or something similar to interact with it locally. The basics of source control are you import your current set of files, then you checkout your repository so you can work locally, and as you make milestones/changes you commit them back to the repository.

    Here is a good read and a few of their examples are using SVN:
    http://betterexplained.com/articles/...rsion-control/

    Hey Cp :-)

    I'm gonna have to recommend using mercurial or git over svn. I used svn myself for a few years and couldn't see anything at all wrong with it. Sure, Mercurial and Git are much faster and can work offline - also supporting different workflows, but I still didn't see this as an absolute essential or anything like that.

    The moment I changed my mind about this was the first time I got my head around how branching works in Mercurial (Mercurial and Git are both very similar, but we use Mercurial at work - the way branching works is so similar that at least in my use-case you can consider them to be the same). Because I'd used svn for years, I was scared of branching (had only ever tried it at a previous company, and the process was a nightmare - took us about a week to do a complicated merge between two branches and everything broke), so I didn't branch for probably the first 3-4 months of working there (thinking back on this, it may have been a good 6 months into my job before I first did it).

    I then came across this scenario: I had a system that was live. I had been working on a new feature for about 2 weeks, but this feature was not yet finished. Because I develop locally, my boss hadn't seen the (unfinished) changes I'd been working on at this point. My boss comes to talk to me to tell me there's a couple of new reports he wants to see on the site, and they are considered a top priority. Now I have a problem - I have two weeks worth of changes that are not yet finished - I must have edited 50 files or more during those two weeks, and now my boss wants some new reports on the site... So how do I make sure none of this unfinished code goes live? In svn, this would have been a nightmare. I'd have probably had to comment out loads of my code to make sure none of the new stuff went live, but when you're dealing with 2 weeks worth of code, it's really messy and not gonna be much fun...

    So I had a go at branching in mercurial. Oh my god - I couldn't believe how good it was. All I did was this - I reverted back in time in my code base to the current live version. I then created a new branch from that point called "new-reports". I then did the work on these reports, got it working and put that code live. This mean my boss could only see the new reports, and that branch had NO code from my unfinished feature on it at all.

    Then comes the really cool part - I then took this branch and merged it into my current working branch with the new, unfinished feature, and good god - it merged instantly. So this meant my dev branch had the new reports + my unfinished code. Eventually I finished this feature, and when it came time to put it live, it had both the new reports + the new feature.

    Seriously, could you do this with svn?

    Just the other day, one of our new web designers (by no means a coder) wanted to be able to edit some design related html/css on our site. No problem. I set him up with his own branch in mercurial and told him how to use it. It's so clean this way, because he can only push to me and my workmate (not to the server). This way, we can assess his changes, make sure he's not done anything silly like edited some php or something, and then when we're happy, we merge his stuff into our branches and it can go live.

    One final real world example - we recently had to do some work with a web design agency on a project. They setup svn on their side, and it was such a nightmare for us. If we're working on a change, we have to contact their guy to make sure we're not gonna put any of his half finished changes live when we put something live ourselves. It's really bad. If we were using Git or Mercurial, we could just put stuff live by using our own branch, and he could merge our stuff into his as he's working on it - it'd be seamless.

    To really see branching in action, check out this video: https://www.youtube.com/watch?v=ZDR433b0HJY

    Check it out from the 22 minute mark. He sets up a local repo and then starts branching - it's like magic, and works just like that in practise :-)

  4. #4
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    One more thing worth mentioning is that branching like this also really encourages experimentation - I have such freedom now, because I can really quickly create a branch and try out an idea. If it doesn't work, no problem - just discard the branch. If it does work, great, you can easily merge your changes into your dev branch and you're all set. The freedom this gives you is very powerful.

  5. #5
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    A very good introduction to mercurial is here: http://hginit.com

    It also has a section dedicated to svn users: http://hginit.com/00.html

  6. #6
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    I then came across this scenario: I had a system that was live. I had been working on a new feature for about 2 weeks, but this feature was not yet finished. Because I develop locally, my boss hadn't seen the (unfinished) changes I'd been working on at this point. My boss comes to talk to me to tell me there's a couple of new reports he wants to see on the site, and they are considered a top priority. Now I have a problem - I have two weeks worth of changes that are not yet finished - I must have edited 50 files or more during those two weeks, and now my boss wants some new reports on the site... So how do I make sure none of this unfinished code goes live? In svn, this would have been a nightmare. I'd have probably had to comment out loads of my code to make sure none of the new stuff went live, but when you're dealing with 2 weeks worth of code, it's really messy and not gonna be much fun...

    So I had a go at branching in mercurial. Oh my god - I couldn't believe how good it was. All I did was this - I reverted back in time in my code base to the current live version. I then created a new branch from that point called "new-reports". I then did the work on these reports, got it working and put that code live. This mean my boss could only see the new reports, and that branch had NO code from my unfinished feature on it at all.

    Then comes the really cool part - I then took this branch and merged it into my current working branch with the new, unfinished feature, and good god - it merged instantly. So this meant my dev branch had the new reports + my unfinished code. Eventually I finished this feature, and when it came time to put it live, it had both the new reports + the new feature.

    Seriously, could you do this with svn?
    Actually, yeah. SVN does branches too.

    Quote Originally Posted by aaarrrggh View Post
    Just the other day, one of our new web designers (by no means a coder) wanted to be able to edit some design related html/css on our site. No problem. I set him up with his own branch in mercurial and told him how to use it. It's so clean this way, because he can only push to me and my workmate (not to the server). This way, we can assess his changes, make sure he's not done anything silly like edited some php or something, and then when we're happy, we merge his stuff into our branches and it can go live.
    This example, on the other hand, does require a distributed version system. In SVN, there's only one server you can commit to. The rest of us only have working copies. Whereas in a distributed system, we clone the repo, and our copy is then indistinguishable from the master. That allows your designer to commit into your personal copy.

    Quote Originally Posted by aaarrrggh View Post
    One final real world example - we recently had to do some work with a web design agency on a project. They setup svn on their side, and it was such a nightmare for us. If we're working on a change, we have to contact their guy to make sure we're not gonna put any of his half finished changes live when we put something live ourselves. It's really bad. If we were using Git or Mercurial, we could just put stuff live by using our own branch, and he could merge our stuff into his as he's working on it - it'd be seamless.
    SVN does branches too.....
    "First make it work. Then make it better."

  7. #7
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Branching in svn is expensive and messy though. You wouldn't merge 3 or 4 times a day in svn, would you? I found branching and merging very difficult and cumbersome in my experience with svn. Like I said with the example of the external agency we had to work with recently, the issue we were having could have been solved with branching easily, but because they use svn, they didn't branch and so we had to deal with the pain.

    Merging is the real key difference here - merging is simple in git and mercurial, so much so that it's normal to do 3 or 4 merges in a day. It's trivial to create branches for everything. On the project I'm working on now for example, we've probably had between 40-50 branches on the project in total (a 3 month project), and typically we'd have about 5 branches running concurrently at any one time. Again, I highly doubt you work like that if you use svn.

    Added to this is the fact you can use it offline and it's much, much faster than svn. When we had to use svn with this agency, it was such a pain. It felt like a real step back, and I just wouldn't even consider using svn for anything if I had the final say.

  8. #8
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    Branching in svn is expensive and messy though. You wouldn't merge 3 or 4 times a day in svn, would you?
    Actually... yeah. I always thought branching in SVN was simple and straightforward. And merging was equally easy.

    EDIT: Which isn't to say that it's necessarily better than Git or Mercurial, just that your experiences with it seem... unusual.
    "First make it work. Then make it better."

  9. #9
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Here's a screenshot from some of the most recent commits in our project. You can see we're branching and merging for fun. Again, I just don't think a workflow like this would be realistic in svn:
    http://i.imgur.com/pnATw66.png
    pnATw66.png

  10. #10
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Actually... yeah. I always thought branching in SVN was simple and straightforward. And merging was equally easy.
    I'm gonna have to disagree with you there - you must be the first person I've known to say branching is simple in svn - I take it you've experienced using either git or mercurial and how they branch? I think it's far better.

  11. #11
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    For example, would you feel comfortable merging say 2 weeks worth of changes to 50 files in svn?

  12. #12
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    For example, would you feel comfortable merging say 2 weeks worth of changes to 50 files in svn?
    Yeah...
    "First make it work. Then make it better."

  13. #13
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Yeah...
    Well you're the first person I've known to say that.

    Regarding my other question - have you experienced branching in git and/or mercurial?

    Can you describe the process of branching in svn? Let's say you take my first scenario - the example of having two weeks' worth of changes that are unfinished, and then you're asked to add a new "reporting" section to the live site. Can you describe the actual process for branching and merging in svn?

    I'll do the same in mercurial.

    So you update to the live branch:

    hg update live

    you branch from this point:

    hg branch reports

    You can then commit on the branch as normal.

    When it's time to merge, you go to your live branch:

    hg update live

    and merge:

    hg merge reports

    Done.

    What's the subversion process?

  14. #14
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Take a look at this article, and note the "Lightweight Branches: Frictionless Context Switching" section: http://blog.teamtreehouse.com/why-yo...version-to-git

    Git and Mercurial are actually better than svn, they're not just different.

  15. #15
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    No offense, but I don't see SVN having difficult branching/merging strategies either... I've yet to run into a problem with branching and merging where it was unbearable or incredibly difficult. Another thing to keep in mind, the OP is primarily talking about a Version Control for himself, not necessarily a team. In that regard something simple, such as, SVN makes a lot more sense over GIT and Mercurial. GIT and Mercurial can make sense when you need a distributed repo, SVN makes a lot of sense when you don't. I'm not at the point of recommending GIT and Mercurial in this situation since it doesn't seem to make a lot of sense.

    To show how to merge I'd have to know what kind of merge you are referring to (as you can do multiple kinds with SVN). Most cases would follow a feature branch, which would simply use
    Code:
    svn merge --reintegrate current_path url_of_master_branch
    If you are doing team branches (multiple teams developing the same project across their own branches doing weekly merges), then you would most likely merge changesets from the last merge you did
    Code:
    svn merge -r 13:HEAD url_of_master_branch
    Neither of those seem convoluted to me... Plus if you use any IDE with SVN support, this becomes painless. Don't get me wrong, I'm sure GIT and Mercurial are nice and all, but when you speak of ease of use, your way off base. It is far easier to describe the workflow of SVN than it is GIT or Mercurial. Explaining to someone you have multiple repos in multiple locations and you need to know when you want to push changes to each one is complicated. SVN there is only 1 repo and you typically work within a specific branch, it is far easier to describe to a new user (my opinion of course).

  16. #16
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    No offense, but I don't see SVN having difficult branching/merging strategies either... I've yet to run into a problem with branching and merging where it was unbearable or incredibly difficult. Another thing to keep in mind, the OP is primarily talking about a Version Control for himself, not necessarily a team. In that regard something simple, such as, SVN makes a lot more sense over GIT and Mercurial. GIT and Mercurial can make sense when you need a distributed repo, SVN makes a lot of sense when you don't. I'm not at the point of recommending GIT and Mercurial in this situation since it doesn't seem to make a lot of sense.

    To show how to merge I'd have to know what kind of merge you are referring to (as you can do multiple kinds with SVN). Most cases would follow a feature branch, which would simply use
    Code:
    svn merge --reintegrate current_path url_of_master_branch
    If you are doing team branches (multiple teams developing the same project across their own branches doing weekly merges), then you would most likely merge changesets from the last merge you did
    Code:
    svn merge -r 13:HEAD url_of_master_branch
    Neither of those seem convoluted to me... Plus if you use any IDE with SVN support, this becomes painless. Don't get me wrong, I'm sure GIT and Mercurial are nice and all, but when you speak of ease of use, your way off base. It is far easier to describe the workflow of SVN than it is GIT or Mercurial. Explaining to someone you have multiple repos in multiple locations and you need to know when you want to push changes to each one is complicated. SVN there is only 1 repo and you typically work within a specific branch, it is far easier to describe to a new user (my opinion of course).
    Yes, but I think if you look at that link above, you can see how much better branching and merging is in git/mercurial:

    "Before I begin explaining this, which is actually my favorite feature of Git, I need you to do me a favor. Forget everthing you know about branches. Your knowledge of what a ‘branch’ means in Subversion is poisonous, especially if you internalized it pre-1.5, like I did, before Subversion finally grew some basic merge tracking capabilities. Forget how painful it was to merge, forget how long it took to switch branches, forget how impossible it was to merge from a branch more than once – Git gives you a whole new world when it comes to branching and merging.

    In Git, branches are not a dirty word – they are used often and merged often, in many cases developers will create one for each feature they are working on and merge between them possibly multiple times a day, and it’s generally painless. This is what hooked me on Git in the first place, and in fact has changed the entire way I approach my development.

    When you create a branch in Git, it does so locally and it happens very fast. Here is an example of creating a branch and then switching to your new branch to start doing development.

    $ time git branch myidea real 0m0.009s user 0m0.002s sys 0m0.005s $ time git checkout myidea Switched to branch "myidea" real 0m0.298s user 0m0.004s sys 0m0.017s

    It took about a third of a second for both commands together. Think for a second about the equivalent in Subversion – running a `copy` and then a `switch`

    $ time svn copy -m 'my idea' real 0m5.172s user 0m0.033s sys 0m0.016s $ time svn switch real 0m8.404s user 0m0.153s sys 0m0.835s

    Now the difference between 1/3 of a second and 13 seconds (not to mention the time it takes to remember each long URL) may not seem huge at first, but there is a significant psychological difference there. Add to that the fact that your network speed, server load and connectivity status are all factors in Subversion, where it always takes 1/3 of a second in Git and that makes a pretty big difference. Also, branching is considered a fast operation in Subversion – you will see even more pronounced speed differences in other common operations like log and diff.

    However, that is not the real power of Git branches. The real power is how you use them, the raw speed and ease of the commands just makes it more likely that you will. In Git, a common use case is to create a new local branch for everything you work on. Each feature, each idea, each bugfix – you can easily create a new branch quickly, do a few commits on that branch and then either merge it into your mainline work or throw it away. You don’t have to mess up the mainline just to save your experimental ideas, you don’t have to be online to do it and most importantly, you can context switch almost instantly.

    Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.

    As an anecdotal case study, take my Pro Git book. I put the Markdown source of the book on GitHub, the social code hosting site that I work for. Within a few days, I started getting dozens of people forking my project and contributing

    copy edits, errata fixes and even translations. In Git, each of these forks is treated as a branch which I could pull down and merge individually. I spend a few minutes once or twice a week to pull down all the work that has happened, inspect each branch and merge the approved ones into my mainline.

    network graph Why You Should Switch from Subversion to Git

    As of the time of writing this article, I’ve done 34 merges in about 2 weeks – I sit down in the morning and merge in all the branches that look good. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes. Once again, I will leave it as an exercise to the reader to contemplate how that would have gone in Subversion.
    Becoming a Code Artist

    You get home on Friday after a long week of working. While sitting in your bean bag chair drinking a beer and eating Cheetos you have a mind blowing idea. So, you whip out your laptop and proceed to work on your great idea the entire weekend, touching half the files in your project and making the entire thing 87 times more amazing. Now you get into work and connect to the VPN and can finally commit. The question now is what do you do? One great big honking commit? What are your other options?

    In Git, this is not a problem. Git has a feature that is pretty unique called a “staging area”, meaning you can craft each commit at the very last minute, making it easy to turn your weekend of frenzied work into a series of well thought out, logically separate changesets. If you’ve edited a bunch of files and you want to create several commits of just a few files each, you simply have to stage just the ones you want before you commit and repeat that a few times.

    $ git add file1.c file2.c file3.c $ git commit -m 'files 1-3 for feature A' $ git add file4.c file5.c file6.c $ git commit -m 'files 4-6 for feature B'

    This allows other people trying to figure out what you’ve done to more easily peer-review your work. If you’ve changed three logically different things in your project, you can commit them as three different reviewable changesets as late as possible.

    Not only that, which is pretty powerful in itself, but Git also makes it easy to stage parts of files. This is a feature that has prevented coworkercide in my professional past. If someone has changed 100 lines of a file, where 96 of them were whitespace and comment formatting modifications, while the remaining 4 were significant business logic changes, peer-reviewing that if committed as one change is a nightmare. Being able to stage the whitespace changes in one commit with an appropriate message, then staging and committing the business logic changes seperately is a life saver (literally, it may save your life from your peers). To do this, you can use Git’s patch staging feature that asks you if you want to stage the changes to a file one hunk at a time (git add -p).

    These tools allow you to craft your commits to be easily reviewable, cherry-pickable, logically seperate changes to your project. The advantages to thinking of your project history this way and having the tools to easily maintain that discipline without having to carefully plan out every commit more than a few seconds before you need to create them gives you a freedom and flexibility that is very empowering.

    In Subversion the only real way to accomplish the same thing is with a complicated system of diffing to temporary files, reverting and partially applying those temporary files again. Raise your hand if you’ve ever actually taken the time to do that and if you would consider the process ‘easy’ in any way. Git users often do this type of operation on a daily basis and you need nothing outside of Git itself to accomplish it."
    Also, I'd still recommend using git or mercurial over svn, even for a single developer. For one, you can use both offline and they are much, much faster than svn, but also, and I'm just gonna repeat myself here - branching and merging is far superior. See the above quote...

    I find svn really painful to use. Like I say, using it for this recent project (where we were forced to) felt so painful. It definitely felt like a backwards step to me.

    What I would say though is that a really nice version control client can make a big difference. I run on a mac and use source tree: http://www.sourcetreeapp.com/ This app has just been released in beta version on windows, and makes the whole process so much more simple. Using this, I really don't think you can argue svn is more simple - I'd argue it's actually more difficult. To setup an svn repo, you require a server and have to mess about setting up the repo. To start a repo in git, you do this: "git init". To start a repo in mercurial you do this: "hg init". It's true that git/mercurial can handle more complex workflows than svn, but it's also the case that for quite simple usage, I think they're actually easier to use + you get the benefits of superior branching and merging.

  17. #17
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    Branching in svn is expensive and messy though.
    I'd like more explanation why you find it expensive. It isn't like SourceSafe where branches actually created copies of each file. Instead of only creates copies of files that are actually changed, the others are links to the original files. So I'm not sure I see the "expensive" side of things.

    I can still do it all from a command line (if I so desire) or within an IDE. It doesn't take long for the branch to be created and checked out, so I'm just not seeing this description being accurate. Maybe you just had a bad experience because your workflow didn't match with SVN or your branching strategy wasn't up to par with a Centralized Version Control.

  18. #18
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    I'd like more explanation why you find it expensive. It isn't like SourceSafe where branches actually created copies of each file. Instead of only creates copies of files that are actually changed, the others are links to the original files. So I'm not sure I see the "expensive" side of things.

    I can still do it all from a command line (if I so desire) or within an IDE. It doesn't take long for the branch to be created and checked out, so I'm just not seeing this description being accurate. Maybe you just had a bad experience because your workflow didn't match with SVN or your branching strategy wasn't up to par with a Centralized Version Control.
    Taken from the article I linked to:

    Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.
    It's not so much branching, as it is merging that is better in DVCS. There's also the fact that when you switch between branches, you instantly switch between them in your working copy, so there's just no messing about. The way merging works in DVCS is almost like voodoo - it just works so smoothly it might as well be black magic at times.

    Put it this way - would you have 5 concurrent branches running at the same time in svn and find it trivial to merge them all together at the correct times? What about doing this while at the same time being able to easily commit bugfixes (hotfixes) on the live branch, and merge those same bugfixes into your branches if required?

    It takes me less than a second to create a branch in mercurial, and I can switch between branches in a second - every time I switch, it switches my working copy so I can see the branch I'm on instantly. If I want to merge it's easy, and just takes seconds. This is not the experience I've had with svn.

    There's no need for the whole "trunk" and "branches" directories in mercurial/git, because you just context switch cheaply and instantly. I can switch to my colleague's branch to see what he's doing and see if his stuff is working, commit any changes I need to make to his branch and then switch back to my own branch in seconds. If I'm happy I can merge these branches whichever way I want, and we can do this even with 10 people working on say 15 branches at the same time if you really want to - all of it done quickly, offline (if necessary) and what's more - cheaply.

  19. #19
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    To start a repo in git, you do this: "git init". To start a repo in mercurial you do this: "hg init". It's true that git/mercurial can handle more complex workflows than svn, but it's also the case that for quite simple usage, I think they're actually easier to use + you get the benefits of superior branching and merging.
    You mean to tell me svn import url ./ is not simple? I'm sorry, but how is that much different than git init (I could script an alias called svn init and tada!)? I could do that locally too, if I wanted, but you lose all the benefits of doing it locally, you lose your local machine due to an idiotic command line execution or a dying hard drive and you are still screwed. You need a remote server period.

    Your reasons seem purely personal. I don't see anything special about the way it branches or merges that is inherently different to SVN. branching is branching, merging is merging. If you do it often you won't run into many problems with differences in files that result in conflicts. If you do it after a long time inbetween, be prepared for conflicts and resolve them. In both scenarios you will always have the ability to run your project again before committing it to the target branch.

    I still think you are caught up in an experience you had due to improper layout/workflow. I'm working in TFS a lot of late which is very similar to SVN workflow and we have 8 teams all interacting with each other. We have no problems with branching and merging (and this system is massive we are talking hundreds of gigs of code/data). I just don't see how recommending something that is designed for a team workflow for a single developer makes sense. He can always convert to git and mercurial when the need arises, but I find it much better to start with something straight forward that is already packaged on most servers (and control panels) before going the route of having to setup/install a system that is meant for so much more.

    Plus I could easily name off a dozen tools for SVN that make life easier too, but that really isn't the point.

  20. #20
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    I must use a much more refined workflow, as I rarely have conflicts with SVN merging.... Oh well. I still don't see the big deal. I don't have to spend hours on end merging with the workflow we have established nor does anyone else... Personally I just think the issues people have with SVN is they did it backwards. They created their web of branches wrong and they are now paying the price for it. If you think about what you need upfront and create it properly there is very little concern with merging, it just works as intended.

  21. #21
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    You mean to tell me svn import url ./ is not simple? I'm sorry, but how is that much different than git init (I could script an alias called svn init and tada!)? I could do that locally too, if I wanted, but you lose all the benefits of doing it locally, you lose your local machine due to an idiotic command line execution or a dying hard drive and you are still screwed. You need a remote server period.

    Your reasons seem purely personal. I don't see anything special about the way it branches or merges that is inherently different to SVN. branching is branching, merging is merging. If you do it often you won't run into many problems with differences in files that result in conflicts. If you do it after a long time inbetween, be prepared for conflicts and resolve them. In both scenarios you will always have the ability to run your project again before committing it to the target branch.

    I still think you are caught up in an experience you had due to improper layout/workflow. I'm working in TFS a lot of late which is very similar to SVN workflow and we have 8 teams all interacting with each other. We have no problems with branching and merging (and this system is massive we are talking hundreds of gigs of code/data). I just don't see how recommending something that is designed for a team workflow for a single developer makes sense. He can always convert to git and mercurial when the need arises, but I find it much better to start with something straight forward that is already packaged on most servers (and control panels) before going the route of having to setup/install a system that is meant for so much more.

    Plus I could easily name off a dozen tools for SVN that make life easier too, but that really isn't the point.
    The point with git/hg init though is that you're up and running with version control on your local machine instantly. You can push this to a remote server whenever you want, and it's really easy. Point is, you can be using all the benefits of version control in a matter of 1 second. It takes 1 second to setup a local repo, and you can push that to a remote server and use it in a similar way to how you use svn really easily.

    Here's another article that has info on the differences (including branching): https://git.wiki.kernel.org/index.php/GitSvnComparison

    Here's an article that does a side by side comparison of branching between git and subversion: http://markmcb.com/2008/10/18/3-reas...om-subversion/

    The way git/mercurial handles branching and merging is different to svn, and it's far better in the DVCS model. Take a look at the above article.

    I'm guessing you've not really spent much time using git or mercurial, which may be why you think the way svn handles branching is acceptable. All I can say is that I was forced to handle svn recently and it felt like a major step backwards - it's just not very nice to use - it's slow, cumbersome and gets in the way. I used to like it when I used it before I switched to mercurial, but since I understood how branching and merging work in mercurial, there's just no way I could go back to svn.

    And I still think it's easier to use git or mercurial than it is to use svn - to use it locally for one developer, you don't even need a server - you're up and running in seconds with no messing about.

  22. #22
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    I'd recommend just giving mercurial a try in your spare time. Have an experiment with branching, and see what you think.

    Check this site out: http://hginit.com

  23. #23
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,215
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    The only real benefit I find immediate of git/mercurial is that you don't really have to think about your branch structure, as most merges are treated or act like a baseless merge. SVN on the other hand works better with a structured branch/merge workflow, you go from this branch to this one, then this one, last prod. The same doesn't hold true for git/mercurial and I think that is what everyone enjoys most is you don't have to follow a structured branch workflow. You can go from branch X to prod without any of the in between branches being involved. Granted, you can do this in other version controls too, it isn't as obvious though.

    Unfortunately, you can't ever sell me that creating repos locally is ever a good thing. I just don't see the purpose as you aren't getting the benefit you really need -- your source on a remote location so if something happens locally, you aren't screwed. That just won't sell me on git or mercurial as it fails to protect you and your code, regardless of how easy it is to do it (that just means people will continue to do it and potentially lose their changes/data for not pushing it to a remote location much more).

    Oh well, I'll leave my two cents at that and simply say, all of the pages you link to purely show that they needed a distributed system for their workflow. That isn't a clear cut case for everyone needs it. There are specific times when it makes sense to make that move, and there are clear indicators that you don't need to as well. Just because you can use it, doesn't mean you need it. If you do not have a defined workflow in place you are purely using a DVCS because you don't understand your workflow and it stops you from having to think about it. That is still dangerous in my opinion and although it has made your life easier, your development cycle might not be as refined as it could be.

    The place I worked prior, was using TFS and I've already mentioned that is similar to SVN, and we would create 30+ branches a month! We'd merge them rarely having to deal with a conflict because our workflow defined the structure and the structure was setup for our development cycle. We never had conflicts or collisions, we could spawn up instances of our apps quickly without having to alter configuration files or having to manually change local files, it was seamless, but it definitely wasn't a DVCS. The Linux kernel team needed a DVCS, they development cycle called for it, and they have a workflow in place that properly supports their DVCS initiative. I've worked with in SVN repos that would benefit from a DVCS model and I've worked in ones that just needed to be restructured because they failed to exhibit their development cycle properly.

    For a one man team, an SVN repo is more than sufficient and usually a very good start, especially from a beginner perspective. You need to learn a LOT of lessons before moving into a system that lets you do anything you want. SVN will teach those lessons and eventually show/tell you when you've out-grown its system and need to move up.

  24. #24
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    The only real benefit I find immediate of git/mercurial is that you don't really have to think about your branch structure, as most merges are treated or act like a baseless merge. SVN on the other hand works better with a structured branch/merge workflow, you go from this branch to this one, then this one, last prod. The same doesn't hold true for git/mercurial and I think that is what everyone enjoys most is you don't have to follow a structured branch workflow. You can go from branch X to prod without any of the in between branches being involved. Granted, you can do this in other version controls too, it isn't as obvious though.

    Unfortunately, you can't ever sell me that creating repos locally is ever a good thing. I just don't see the purpose as you aren't getting the benefit you really need -- your source on a remote location so if something happens locally, you aren't screwed. That just won't sell me on git or mercurial as it fails to protect you and your code, regardless of how easy it is to do it (that just means people will continue to do it and potentially lose their changes/data for not pushing it to a remote location much more).

    Oh well, I'll leave my two cents at that and simply say, all of the pages you link to purely show that they needed a distributed system for their workflow. That isn't a clear cut case for everyone needs it. There are specific times when it makes sense to make that move, and there are clear indicators that you don't need to as well. Just because you can use it, doesn't mean you need it. If you do not have a defined workflow in place you are purely using a DVCS because you don't understand your workflow and it stops you from having to think about it. That is still dangerous in my opinion and although it has made your life easier, your development cycle might not be as refined as it could be.

    The place I worked prior, was using TFS and I've already mentioned that is similar to SVN, and we would create 30+ branches a month! We'd merge them rarely having to deal with a conflict because our workflow defined the structure and the structure was setup for our development cycle. We never had conflicts or collisions, we could spawn up instances of our apps quickly without having to alter configuration files or having to manually change local files, it was seamless, but it definitely wasn't a DVCS. The Linux kernel team needed a DVCS, they development cycle called for it, and they have a workflow in place that properly supports their DVCS initiative. I've worked with in SVN repos that would benefit from a DVCS model and I've worked in ones that just needed to be restructured because they failed to exhibit their development cycle properly.

    For a one man team, an SVN repo is more than sufficient and usually a very good start, especially from a beginner perspective. You need to learn a LOT of lessons before moving into a system that lets you do anything you want. SVN will teach those lessons and eventually show/tell you when you've out-grown its system and need to move up.
    Well, with regards to the local repo thing - I'd argue the opposite actually. If you're interested in making sure your code is safe, the local repo + server model works far better. Look at it like this - say you have 5 developers working on a project, with one centralised server - with DVCS, this means you have a minimum of 6 copies of the entire repo. If the server has a hard drive failiure, that's just one node, which means you have 5 other copies all ready to replace it. Subversion is actually LESS protective of your code and source control history, because even if you have 100 developers working on a project, you still have a single point of failure - lose that server, and you lose your entire version control history - so it's actually worse for protecting your code.

    What's more, being able to commit locally means the experience of using version control is MUCH faster. Every operation is more or less instant. Using svn means you call a command and have to wait like 5-10 seconds for everything. It's not a good user experience.

    It also means you can really easily do experiments - you can clone your own repo onto your local machine again if you want and do all kinds of experiments with it - if it works, you can push back to the server, and if it doesn't you can just remove that entire clone. This means you can use version control and have all the benefits without having to connect to the server each time, but when you're ready to share your work, you do a push and it's there for all to see. The distributed model is better in every single use case. I don't think you could give me a single example where the purely centralised model is better.

    Even for a single man project, I still think the DVCS is better, because it's capable of handling a simple workflow too, and when you want to move upwards, it's just a matter of learning how to do so. Svn requires a server even for a one man project, which doesn't really make much sense to me. If you want the server you can do that anyway, but it's great to be able to get up and running really quickly. You lose nothing - if you want a server it's easy to do, if not that's easy to do too.

    The idea of needing to connect to a server just to see how a file has changed over time seems so old fashioned and cumbersome to me. It's painful, and it doesn't need to work that way.

    Another significant gripe with svn - those horrible .svn directories you get in every single directory in your project. Always used to hate that too - but again, this just doesn't happen with git/mercurial.

    I can't see any advantage to using svn under any conditions - honestly, I think git/mercurial win in every use case I can imagine.

  25. #25
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Again, from the above article:

    As of the time of writing this article, I’ve done 34 merges in about 2 weeks – I sit down in the morning and merge in all the branches that look good. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes. Once again, I will leave it as an exercise to the reader to contemplate how that would have gone in Subversion.
    I'll probably just leave it there now.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •