SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 36 of 36

Thread: Version Control

  1. #26
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    This conversation exploded while I was away.

    Quote Originally Posted by aaarrrggh View Post
    Well you're the first person I've known to say that.
    Ditto, but the opposite.

    Quote Originally Posted by aaarrrggh View Post
    Regarding my other question - have you experienced branching in git and/or mercurial?
    Yup. I first learned distributed VCS with Mercurial, and I used Git on a project about a year ago.

    Quote Originally Posted by aaarrrggh View Post
    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?
    If you were making intermediate commits during those two weeks, then you would have created a branch right from the get go. Once your feature is ready to go live, you can merge that branch into the trunk. Not much else process to describe here. The merge would complete automagically.

    Quote Originally Posted by aaarrrggh View Post
    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?
    Literally exactly the same. Branch from the trunk. Commit to the branch as normal. When it's time to merge, just run merge. Done.
    "First make it work. Then make it better."

  2. #27
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    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".
    To start a repo in SVN... "svnadmin create".
    "First make it work. Then make it better."

  3. #28
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,067
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    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.
    Your assumption is that you pushed it to other locations. If you only created it locally and never pushed that branch out to anywhere else, you don't have that at all, you have a single point in failure. My concern is people will create it local and not push it until its ready (I could be wrong here, as maybe it does push the branch immediately to all nodes, but I personally wouldn't think it would; but please correct me if I'm wrong ) whereas with SVN you are required to have it remote immediately.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  4. #29
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    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.
    By and large, I actually agree with this statement. Although, I think your experiences with SVN are a-typical and, frankly, more likely due to a misunderstanding and misuse of the tool. Nonetheless, I fully agree and acknowledge that Git/Hg can do everything SVN can do, plus more.

    The reason I personally haven't made the switch yet comes down to one very specific reason. I significantly prefer to use GUIs than the command line, especially for VCS. When I was using Git about a year and a half ago, the best GUI client I could find was TortoiseGit, and it was atrocious. It was ridiculously slow, and if I needed to commit a large number of files, such as to add Symfony or Zend Framework, then it was 50/50 whether TortoiseGit could even complete the operation. Often times, it would simply crash.

    Though, I did notice your link to the client SouceTree, and that there's a Windows beta. Perhaps I'll once again browse around and see how well the GUI client situation has improved.
    "First make it work. Then make it better."

  5. #30
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    By and large, I actually agree with this statement. Although, I think your experiences with SVN are a-typical and, frankly, more likely due to a misunderstanding and misuse of the tool. Nonetheless, I fully agree and acknowledge that Git/Hg can do everything SVN can do, plus more.

    The reason I personally haven't made the switch yet comes down to one very specific reason. I significantly prefer to use GUIs than the command line, especially for VCS. When I was using Git about a year and a half ago, the best GUI client I could find was TortoiseGit, and it was atrocious. It was ridiculously slow, and if I needed to commit a large number of files, such as to add Symfony or Zend Framework, then it was 50/50 whether TortoiseGit could even complete the operation. Often times, it would simply crash.

    Though, I did notice your link to the client SouceTree, and that there's a Windows beta. Perhaps I'll once again browse around and see how well the GUI client situation has improved.
    Yeah, it's interesting you should mention the lack of decent gui support for windows. I've been using sourcetree on the mac for over a year now (and love it), but haven't used a windows machine in a few years.

    As I stated above, we recently gave a graphic designer access to our source control, so he could make design related changes (our flow dictates that he can only push to me and my colleague directly - he's not able to push to the main server, so we vet everything he does to make sure he doesn't do anything silly like edit some php or anything like that). As part of this process, I needed to create a vagrant box for him, so he could have a reliable environment on windows. While testing on windows myself, I searched for a decent gui, assuming that there would be one somewhere, and just couldn't find anything. Funnily enough, literally the day after struggling to find a gui for windows (and bear in mind, this was only last week), sourcetree for windows was released in beta form. It currently only supports Git (the Mac version supports Git + Mercurial), but it's well worth your time. It's largely due to this gui tool that I "got" DVCS, and I still use it every day in work. Take a look at it!

  6. #31
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    Your assumption is that you pushed it to other locations. If you only created it locally and never pushed that branch out to anywhere else, you don't have that at all, you have a single point in failure. My concern is people will create it local and not push it until its ready (I could be wrong here, as maybe it does push the branch immediately to all nodes, but I personally wouldn't think it would; but please correct me if I'm wrong ) whereas with SVN you are required to have it remote immediately.
    I do see your point, but even if you only ever keep things local, you still have the same number of points of failure as svn - one. The moment you push to a remote location, you instantly have two points of failure, and this obviously increases whenever someone clones the repo. With svn, it always stays the same. Again, in an svn based system, 100 developers working on a project = 1 point of failure, whereas with a DVCS, 100 devs = at least 101 points of failure, although there could easily be more, as some devs will even clone their local repo for experiments and things like that.

    Generally btw I tend to push to a remote location more or less instantly, usually on the first commit. However, sometimes, if I'm just doing something quick like say a small script or say a bug fix on another system (in which case maybe I'll just download the files directly to my machine before creating a local repo), just locally doing it is fine and still gives you the benefits of version control for the brief amount of time you require it. I can still branch and merge and flip backward in time + see all changes etc directly on my local machine.

    Depends what I'm working on basically. For the vast majority of use-cases, I'll push to a remote location very quickly, and from that point on, I've already doubled the number of points of failure in my workflow compared to svn, and it only increases from there.

  7. #32
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Here's a nice intro video to sourcetree (3 mins long): https://www.youtube.com/watch?v=lDUOvLE8T4o

  8. #33
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,067
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    I do see your point, but even if you only ever keep things local, you still have the same number of points of failure as svn - one. The moment you push to a remote location, you instantly have two points of failure, and this obviously increases whenever someone clones the repo. With svn, it always stays the same. Again, in an svn based system, 100 developers working on a project = 1 point of failure, whereas with a DVCS, 100 devs = at least 101 points of failure, although there could easily be more, as some devs will even clone their local repo for experiments and things like that.
    No, I have two with SVN from the start. My local copy and the server copy. Plus anyone else who checkouts the repo has a copy... sure they can't sync up anymore if the server goes down, but that is okay, wouldn't want them to. Plus I then really only need to backup one location, a good proven backup system will save my single server and allow me to restore it fairly quickly. I don't really see your point personally. There is a reason why it was done fine for years, and continues to be fine for many companies for many more years -- they don't have an immediate need for a DVCS.

    DVCS isn't right for everyone and seriously, if you are a one man team, a DVCS makes little to no sense. You will likely have a remote off-site server you push to and your local machine. You basically have SVN.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  9. #34
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    No, I have two with SVN from the start. My local copy and the server copy. Plus anyone else who checkouts the repo has a copy... sure they can't sync up anymore if the server goes down, but that is okay, wouldn't want them to. Plus I then really only need to backup one location, a good proven backup system will save my single server and allow me to restore it fairly quickly. I don't really see your point personally. There is a reason why it was done fine for years, and continues to be fine for many companies for many more years -- they don't have an immediate need for a DVCS.

    DVCS isn't right for everyone and seriously, if you are a one man team, a DVCS makes little to no sense. You will likely have a remote off-site server you push to and your local machine. You basically have SVN.
    Ah hang on, but when you talk about people checking out - you understand the difference there between a checkout in svn and a clone in git/hg? When you have a copy on your local machine in svn, you only have the working copy - that is, you're not actually cloning the entire repo and all the vc history. Whenever someone clones a repo in git/hg, they don't just get the working copy - they get the entire vc history of the entire project, so you have a complete copy of the repo. Yes, it's true that in svn you'd have copies of the latest working copy, but in the case of a hard drive failure on the server, you'd lose all the vc history, whereas in git/hg, you wouldn't. This is what I mean when I say your source is actually safer using git/hg.

  10. #35
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,067
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    That is a fair point, but I'd argue, I rarely care about the entire vc history if I know the trunk to be true and already in prod. For feature branches, that "may" be useful, but I'd still argue its usefulness. Please don't take this link as a hit against GIT as that's not my intention, but rather, the setup/workflow of your GIT or SVN is very important, be sure you are 1) using the right tool for the given job and 2) that you are using the specified version control properly, otherwise you may run into dire consequences (unfortunately, the KDE team setup GIT wrong in a very bad way).
    http://it.slashdot.org/story/13/03/2...tm_medium=feed
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  11. #36
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    That is a fair point, but I'd argue, I rarely care about the entire vc history if I know the trunk to be true and already in prod. For feature branches, that "may" be useful, but I'd still argue its usefulness. Please don't take this link as a hit against GIT as that's not my intention, but rather, the setup/workflow of your GIT or SVN is very important, be sure you are 1) using the right tool for the given job and 2) that you are using the specified version control properly, otherwise you may run into dire consequences (unfortunately, the KDE team setup GIT wrong in a very bad way).
    http://it.slashdot.org/story/13/03/2...tm_medium=feed
    Fair enough. Look, if it works for you then it works for you. I can only say that in my experience I much prefer git and mercurial over svn, and that when I had to use svn recently I really didn't like it. A lot of that is just down to general user experience stuff too - like the fact that you have to wait after issuing any command. I'm so used to stuff happening instantly that even that felt like a step back to me.

    There's no point arguing over stuff like this though really - fact is, you have a workflow that works for you, and I've got a workflow that works for me


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
  •