   I do not understand Version Control
  I grabbed a copy of Bazaar as my first VCS. I'm playing with it and looking at the docs, but I have no idea what any of the terms mean or how to interface with a VCS in general. What do I need to understand before I can even use a VCS at all? I use VS10 (Typically VC++)   
  If you're new to version control, then there certainly are going to be a lot of new terms and concepts you'll need to learn.  However for the most part you can learn these things slowly over time on a need-to-know basis.  Your common, everyday workflow with a VCS goes something like:1)  Check out file.  This makes it writable on your machine and indicates to the VCS that you're in the process of editing it.  Certain files (i.e. binary) that you check out will be locked to other users, which prevents them from also checking out the file and editing it.2)  Edit file.3)  Check-in file.  These will update the revision number on the file, create a new changelist, and make your changes "official".  You might have to resolve the file, which means someone else changed it and checked it in while you were working on it, and you need to merge your two changes together.  For the most part, when the changes are in different parts of the file this is a smooth process.  This also explains why certain files have exclusive check-out, since merging them wouldn't be a sensible operation.  When others sync to the latest changelist, they will get everything that's been changed and submitted since their last sync.Once you're familiar with those fundamental steps, you can move on to dealing with multiple branches, integrations, etc., that really make a version control system shine.   ; This is a pretty painless guide to source control in general and  this builds on that to explain the concepts behind distributed source control (which what Bazaar is). If you're completely new to version control I would recommend using a non-distributed program first. I think it makes more sense that way, though there are some who disagree with me.   ;  The guids above cover all the workings of a VSC. The next thing you need to think about is your workflow has to change.1) You plan out a chunk of work.2) If it is a LOT of work, or you use GIT, you start a branch.3) You check out files4) You start to make edits.5) As you edit, when you see progress you don't want to lose, you check in.6) You've finished your chunk of work, do a final check in of anything that is left.7) If you started a banch, integrate the branch back into everyone else's code. If you didn't branch, they already have access to everything.8a) In a DVCS like Bazaar, GIT, or Mucurial, you also have to deal with eventually pulling from other people (having them pull from you) to get that top level of changes.The idea is to check in working parts of code often, so that you have a reference to go back to if you end up breaking what you thought was working 5min ago.In a group, you also have to be sure your check in doesn't break the program for other people.  This usually means, without a branch, you skip step #5. If you aren't using a personal branch, focusing your work into small chunks helps reduce the problem of not being able to check in often.  VSCs like GIT also help this with their painless branching compared to something like Perforce.Quote:If you're completely new to version control I would recommend using a non-distributed program first.I think it makes more sense that way, though there are some who disagree with me.I hated SVN in school. It never made any sense to any of us working on a project. At my first game job, we use SVN then Perforce. Perforce made a lot more sense than SVN, and I finally got a hang of what VCS was doing.  Though, now that i use GIT at home, I really really wish I'd used GIT from the start, it makes local version control almost as easy as just saving your files.  It isn't till you have to deal with a workflow that includes other people that i think the DVCSs get way more complicated than the regular VCSs.  And I think that is partly why i still use my DVCS like a VCS, by having a "main" repository i pull changes to every once in a while.OP: If you do try switching from a DVCS to a VCS, try Perforce.   ;  Distributed vs. Centralized is very much a different mindset -- I'll agree that the model used by the centralized systems is more familiar, as anyone who's used a library can follow the check-out, check-in model, or anyone who has tried to do "manual" source control with a small group.That said, there are serious drawbacks to the centralized systems, the major one being that only one person may work in a file at a given time -- If someone needs changes to a file someone else has checked out to continue their work, then they need to either a) contact that person, and ask them to implimnet the change and check in (which the state of their other work may not be ready for), or b) unlock the necessary file locally, make their changes, and then offer over the necessary changes to the other programmer behind the back of the VCS software, foregoing all the benefits thereof (in particular, you now have one set of new functionality in two different check-ins from two different programmers!)I had been a devotee of Subversion for quite some time -- and I'd maintain that its among the best, if not the best, of the centralized systems. However, after being introduced to Mercurial (A distributed system like Bazaar or Git) and reading up on its workflows and proper use, I've really fallen for the distributed model.One of the big hurdles to understanding the distributed systems is that is seems like there's no central authority over the repo -- which isn't the case. being "distributed" sounds like a scary thing when you're talking about many developers too. However, the ability to quickly and easily branch and merge is a godsend that easily allows a hierarchical structure that mirrors the project teams.Starting at the bottom, an individual developer will typically have an "inbound" repo which has the last-known-good source from his feature team, and an "outbound" repo which contains all of his changes that he considers worthy of submitting. He does all his coding in personal, experimental branches until he's happy with what he's got.His feature team manager owns the feature team's inbound and outbound repos, which contain the LKG source of, and changes to be submitted to the product team. Before it hits the product team, however, the feature team changesets might be merged to feature-level testers' repo to be veted before those changes are merged with the product team's repo.Likewise, the product team will have product-level testers who vet the product as a whole before changes are merged into the product repos (perhaps one for retail, one for debug, one for test, etc).This gives a really nice split of responsibilities, as everyone is only concerned with what they should be, and experimental or rejected changes don't get propagated up the tree any further than they need to be, increasing clarity.Now, maybe this sounds good but "too heavy" for a small team. The nice thing is that you get to decide how many layers there are, even just one. Using one repo as an idividual is basically a more-convenient form of a centralized system, so no loss and some gain. Using a single repo in a small team of 2-3 people working tightly is much the same story. When you get to people or teams owning distinct areas of the codebase, then the distributed model really begins to shine, and at this point, if you're using a distributed system like it were a centralized system, you really start loosing out on the benefits -- and I'd strongly recommend (a possibly-shallower-version-of) what I described above.I've been using a shallow version of this for my homework projects for awhile, and its really great to be able to make a branch and play around with or experiment on without worrying about poluting the source tree with code that doesn't pass muster.   ;Quote:Original post by KulSeranOP: If you do try switching from a DVCS to a VCS, try Perforce.Just note that for proprietary applications it's $740 per user per year (subject to yearly change) without support, and if it's open source you have to jump through some hoops to get a license free of charge.  I do hear it's quite nice (at least to use), but I doubt the casual developer would spring for that.  Especially if he's just trying to get a feel for version control in general - when applying for the free license you have to give your server IP address, OS, number of users, and project license, and you aren't allowed to use it on any other project without a separate license.Anyway, I just wish we used any of the above mentioned where I work, even Subversion.  Maybe we just don't have it set up very nicely, but Telelogic Synergy makes me want to stab my brains out.   ;Quote:5) As you edit, when you see progress you don't want to lose, you check in.6) You've finished your chunk of work, do a final check in of anything that is left.7) If you started a banch, integrate the branch back into everyone else's code. If you didn't branch, they already have access to everything.8a) In a DVCS like Bazaar, GIT, or Mucurial, you also have to deal with eventually pulling from other people (having them pull from you) to get that top level of changes.Is it just me, or does this process sound like it needs moderation/automation? This sounds like a daunting process for just saving a copy of a file.@RavyneLet me see if I understand you: A DVCS splits work into safe, logical areas that allow for experimentation by several departments. Once something good comes out a branch, the higher ups can check it in it closer to the trunk to update the whole organization?With what lmelior said in mind, I should note that I am completely alone here.   ;Quote: by RavyneThe major one being that only one person may work in a file at a given time -- If someone needs changes to a file someone else has checked out to continue their work, then they need to either a) contact that person, and ask them to implimnet the change and check in (which the state of their other work may not be ready for), or b) unlock the necessary file locally, make their changes, and then offer over the necessary changes to the other programmer behind the back of the VCS software, foregoing all the benefits thereof (in particular, you now have one set of new functionality in two different check-ins from two different programmers!)WHAT!??????What system makes you do that? Perforce atleast lets anyone who wants to work on text files. They all get checked in, and merged. No sharing outside the VCS. No having to deal with someone else having the same file checked out.  That said, your scenario does happen with un-mergeable binary files, but those hopefully aren't something everyone needs to edit.Quote:by lmeliorI do hear [perforce] is quite nice (at least to use), but I doubt the casual developer would spring for that. Free for personal use with only one user (2 users, but one has to be the admin account that you can't use).Quote:Let me see if I understand you: A DVCS splits work into safe, logical areas that allow for experimentation by several departments. Once something good comes out a branch, the higher ups can check it in it closer to the trunk to update the whole organization?Something like that. It also gives you a full copy of all the history you know about. All the centralized VCSs require you to have connection access to the server to query for history.Quote: by zyrolastingIs it just me, or does this process sound like it needs moderation/automation?You can automate parts of it. Like you can have it check in a copy every time you successfully compile. But the hard part is you can't really automate the determination of "i'm done with this part, lets save a copy".  And it is that "i'm done with this" part that you really want to be checking in on so as to not clutter your history with too many random changes.Quote:This sounds like a daunting process...The only daunting part of it is working with other developers, because that puts limits on what you can check into the main branches (ie it has to work). As well as the fact that two people working in the same file will eventually cause merge conflicts that require manual attention.Quote:...for just saving a copy of a file.But you AREN'T "just saving a copy". You are saving a history of what you did in a file, as well as the fact that each check in consists of many files, so it shows their relation as well.I check out some files as i edit them.When i go to check in, i see:engine/graphics.hengine/draw.hengine/graphics.cppshared/errorstrings.cppshared/errorstrings.has one big list that I commit as a whole.  You see all the related files, all the changes, and it all gets stored as a item in the history.[Edited by - KulSeran on May 24, 2010 5:14:47 PM];  There seems to be some confusion here. People are mixing the idea of a DVCS with one that supports/suggests a branch-heavy workflow. The two are only barely related. In particular, every DVCS (that I know of) uses a branch-heavy model of work (because I'm not sure how else it would make sense).But you can use that same workflow with a centralized VCS. PlasticSCM, for example, is havily based on a branch-based development process, and is (generally) centralized. (Although it supports distributed features as well). You can even use a branch-heavy model in Perforce ... although I wouldn't recommend it, as their support for branching is atrocious.And yes, the centralized systems rely on a server to store the "master" copy of the data and associated meta-data (like old revisions and change descriptions). With a DVCS, those things are stored on everyone's machine. If you do want to use a simple centralized VCS (like Perforce), you just end up running the server on your own machine. And yes, you don't need to ask them for a license ... you can run it for free with up to two users. Luckily, you can have multiple client-specs for a single user, so that limitation doesn't really become a problem unless you want to implement some advanced server-side stuff in your depot (like reviews, security, jobs, ...)   ;Quote:Original post by Ravyne[omitted because it's a lot of text to quote :)]A lot of what you describe can be done with a centralized VSC using branches.  While it's not quite the same as DVCS, you can still establish a hierarchical branch structure in which changes are isolated to individual branches until explicitly merged up/down.  Not to mention that with branchspecs, you can enforce merge paths so that someone doesn't go accidentally merging their experimental changes into the RC branch :) (not sure if this concept exists outside of Perforce though).   