Some projects are better suited for Edit + Get/Merge + Commit, while some teams are better suited for Check-out + Edit + Check-in. The debate over which practice is better is largely religious: for every advantage one technique holds over the other, there’s an equal disadvantage. Edit + Get/Merge + Commit – before committing a change to the repository, a developer must get the latest version of the file and merge any changes made since the last time he retrieved it.Check-out + Edit + Check-in – before making any changes to a file, a developer must check-out the file, and while it’s checked-out, no other developers can make changes against it until the file is checked-in.This notion of locking files has created two distinctly different philosophies for maintaining code: Check-in – Unlocking a specific set of locked files and then Committing changes against those files.Check-out – Locking a specific set of files and then Getting the latest revision of those files.Many source control systems will also implement a locking mechanism that prevents a Commit against a specific set of files. Commit – add a specific set of changes to the repository.Get – retrieve a specific set of changes (files, directories, etc) from the repository.There are dozens of different source control systems on the market, but all must implement at least two core operations. It’s not a document manager, an artifact (build output) library, a backup solution, a configuration management tool, etc. Littered with gigabytes of video and picture filesĪ little bit of misuse is okay, so long as you remember that source control is for source code.Document management (such as SVN For HR, or even developer documentation).While the list of what a source control system shouldn’t be used for is near infinite, the top three misuses tend to be: Sometimes that’s okay if you only need to chisel off the smallest bit of debris, but it’s far too easy to mistake your favorite source control system as the golden repository. Just as a flathead screwdriver can be used a chisel, a source control system can be used to do things that are completely unrelated to source control.
SHELVES WITH SUBSHELVES IN DELICIOUS LIBRARY 3 CODE
Source control: change management for source code
With that, we can arrive at fairly broad yet concise definition. There’s one key distinction between revision control and source control: the latter is a specific type of the former. As a whole, a three-dimensional system is known as revision control. This third dimension – the repository – provides a perfect history of changes, allowing one to revert to any state at any time. The second dimension is the world that every computer user lives in, but we know of a third dimension: the delta.Ī delta not only represents the bits that were changed in the first dimension, but also the paths that were changed in the second dimension. Bits 5,883,736 through 6,269,928 now have meaning: they represent C:\Pictures\Kitty.jpg and the adjacent 4,096 bits may contain metadata understood by the file system, such as “date created” and “last modified by user”. The file system intersects this near-infinite line of bits and creates a path. That’s where the second dimension – the file system – comes in.
Whether it’s the 16,000,000 on a 3.5”floppy disk or the 4,000,000,000,000 on a desktop hard drive, bits represent a line – the first dimension – and, in and of themselves, bits are entirely meaningless. It all starts with bits: an unfathomably large and virtually endless stream of 1’s and 0’s. If we’re going to take a good, hard look at source control, let’s do something we should have all done a long time ago, before even touching a source control client. Sure, certain operations may be easier to do – but if they’re the wrong thing to do, then it’s that much easier to make mistakes. This especially holds true with the latest breed of distributed version control systems. And, as someone in a fairly unique position of working with virtually every source control system out there (a hazard of the day job: BuildMaster needs to integrate with them all), I’ve learned that there are far more similarities than differences. Repositories, merging, and committing become second-nature just as easily.īut there’s a whole lot more to source control than just that. We’re already familiar with the nature of files and directories, so introducing the concepts of checking-in and checking-out aren’t a huge leap. now get to work.”įor the most part, that works just fine. Your introduction to source control probably was a lot like mine: “here’s how you open SourceSafe, here’s your login, and here’s how you get your files.
0 kommentar(er)
