Comment On Source Control Done Right

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... now get to work.” [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Re: Source Control Done Right

2011-09-06 07:30 • by ParkinT
After reading this I need to be Committed.
Or, at least, Checked-Out.

Addendum (2011-09-06 07:35):
...use your source control system to properly manage source code changes. That’s why you’re using it in the first place.

That's why I am a huge proponent of 'git'.

Perhaps I need to be Committed.
Or, at least, Checked-Out.

Re: Source Control Done Right

2011-09-06 08:16 • by Wagner (unregistered)
359420 in reply to 359416
ParkinT:
After reading this I need to be Committed.
Or, at least, Checked-Out.

Addendum (2011-09-06 07:35):
...use your source control system to properly manage source code changes. That’s why you’re using it in the first place.

That's why I am a huge proponent of 'git'.

Perhaps I need to be Committed.
Or, at least, Checked-Out.

Oh my. After reading these horrible puns I feel the need to push a fork into you and pull it out repeatedly.

Re: Source Control Done Right

2011-09-06 08:25 • by Dave (unregistered)
I've actually had the conversation about the difference between document management and source control before with co-workers. But I admit to not knowing what to use instead. Any suggestions?

Re: Source Control Done Right

2011-09-06 08:25 • by letseatlunch (unregistered)
is it just me or is any one else feel that they must be in the twilight zone because this was posted before 8:30?

Re: Source Control Done Right

2011-09-06 08:26 • by wva (unregistered)
Why the hell would you want to keep documentation out of the source control system?

What makes a latex/org/... file different from a c/py/.. file? In both cases you want to track and merge changes and see who did what when, and branch as ideas are tried or different "stable" versions are needed...

Re: Source Control Done Right

2011-09-06 08:28 • by Chris Cowdery (unregistered)
Dimension one look like bits to me. Surely they should be broken up into 8 bit blocks to become bytes?

Chris.

Re: Source Control Done Right

2011-09-06 08:30 • by SG_01 (unregistered)
The companies I've worked for so far, as well as the companies I will work for in the future, will always have to store vast amounts of binary data next to the code. And due to requirements it will always have to be in the same system.

But that's game industry for you, assets of one version might not be compatible with assets of a different version, as such the assets are linked to the code, and using multiple systems for that would make life a living nightmare!

Re: Source Control Done Right

2011-09-06 08:30 • by QJo (unregistered)
A few years back I was tasked with merging version 12 into the by now completely different product which was forked off from version 9 (specifically, version 9.4) four years previously. Of course, the QA procedures had since been rewritten, and QA itself had been offshored, so relying on the same test schedule that had been used for version 9.4, 10, 11 and 12 (all versions) would have been inadequate, so 300 pages of QA instructions had to be regenerated from scratch.

There was so much to do and the deadlines were so tight it resulted in me working on the average of 70 hour weeks (all overtime unpaid) and being denied any decent leave for 18 months. Surprise was expressed at my exit interview that one of the reasons I was leaving was that I was tired.

The moral of the story: if you're going to make stupid management decisions, make sure that the engineer who said at the time that it was a stupid idea isn't going to be assigned the task of fixing it, or you may lose him.

Re: Source Control Done Right

2011-09-06 08:33 • by stubola (unregistered)
359429 in reply to 359424
In the codebase I work with, there is a document written in MS Word HTML (don't ask me why; not my decision). While a simple change to a cell in a table looks easy when editing with Word, the underlying HTML seemed to change very drastically with that simple change. Making a patch in SVN with a change of that file ended up just being ridiculous because nobody wanted to go through the crapload of changes. We ended up moving to more of a Wiki system but that, I think, is a good reason why some docs should be left out of a source control system.

Re: Source Control Done Right

2011-09-06 08:35 • by QJo (unregistered)
359430 in reply to 359424
wva:
Why the hell would you want to keep documentation out of the source control system?

What makes a latex/org/... file different from a c/py/.. file? In both cases you want to track and merge changes and see who did what when, and branch as ideas are tried or different "stable" versions are needed...


Documentation is usually written in Word (or using a similarly ill-maintainable program) so in a source-control system usually need to be stored in binary form. In such a form it may not be as easy to establish what the differences are between versions.

If you're maintaining your documentation in e.g. TeX, then it may well be more appropriate to use a source-control system for the docs.

Another option is to use a wiki for the documentation.

Re: Source Control Done Right

2011-09-06 08:43 • by pjt33
359433 in reply to 359429
stubola:
In the codebase I work with, there is a document written in MS Word HTML (don't ask me why; not my decision). While a simple change to a cell in a table looks easy when editing with Word, the underlying HTML seemed to change very drastically with that simple change. Making a patch in SVN with a change of that file ended up just being ridiculous because nobody wanted to go through the crapload of changes.

Sounds remarkably similar to my experience with Visual Studio's designer tools. The only way to get readable diffs is to hand-edit the autogenerated code which you're not supposed to touch.

Re: Source Control Done Right

2011-09-06 08:45 • by The "Real" WTF (unregistered)
mm...is it SourceSafe (who uses source safe??)

or is it writing an educational article about source control in a website dedicated to bad practices?

i think we're long overdue an article about WTF practices.
taken from select implementations on this website through the years and put together into one incoherent collection of WTF practices.

also - how about a WTF rating:
you often here people say "i worked on a really crappy system"
or "you wouldn't believe how bad the code here is"

but these claims are often not backed up due to "copyright" or "theft of source code" or something.
well - i have a solution:
WTF rating - a comparable scale of WTFP (WTF points).
the ratio tries to capture the level of WTFness (bugs, crashes, user complaints, complexity and incomprehensibility) introduced by each WTF.
Points accumulate, reflecting the fact that the larger the system the more WTFs you will find, and the worse off it is.

i.e.
1000 WTFP - Writing your own version of a bool (with that long missing 3rd option)
10 WTFP - giving a variable a meaningless name
20 WTFP - giving a variable an opposite name
50 WTFP - giving a variable an incomprehensible name (NotNonInvisible)

you can also give points to WTFP (WTF Practices)
i.e.
300 - Hiring experts that take months to write their own name in code
500 - Hiring cheap outsourceres that build you a crappy system and then paying 3 times the price to have it fixed
6000 - using ACCESS as a database
..

Finally we can award WTFP (WTF Prizes) to the system with the highest WTFP and WTFP.

Re: Source Control Done Right

2011-09-06 08:58 • by The poop... of DOOM! (unregistered)
359437 in reply to 359436
The "Real" WTF:
mm...is it SourceSafe (who uses source safe??)

or is it writing an educational article about source control in a website dedicated to bad practices?

i think we're long overdue an article about WTF practices.
taken from select implementations on this website through the years and put together into one incoherent collection of WTF practices.

also - how about a WTF rating:
you often here people say "i worked on a really crappy system"
or "you wouldn't believe how bad the code here is"

but these claims are often not backed up due to "copyright" or "theft of source code" or something.
well - i have a solution:
WTF rating - a comparable scale of WTFP (WTF points).
the ratio tries to capture the level of WTFness (bugs, crashes, user complaints, complexity and incomprehensibility) introduced by each WTF.
Points accumulate, reflecting the fact that the larger the system the more WTFs you will find, and the worse off it is.

i.e.
1000 WTFP - Writing your own version of a bool (with that long missing 3rd option)
10 WTFP - giving a variable a meaningless name
20 WTFP - giving a variable an opposite name
50 WTFP - giving a variable an incomprehensible name (NotNonInvisible)

you can also give points to WTFP (WTF Practices)
i.e.
300 - Hiring experts that take months to write their own name in code
500 - Hiring cheap outsourceres that build you a crappy system and then paying 3 times the price to have it fixed
6000 - using ACCESS as a database
..

Finally we can award WTFP (WTF Prizes) to the system with the highest WTFP and WTFP.

7000 WTFP for using VB
7000 WTFP for using PHP

Re: Source Control Done Right

2011-09-06 09:03 • by Paratus (unregistered)
359438 in reply to 359437
The poop... of DOOM!:
The "Real" WTF:

6000 - using ACCESS as a database


7000 WTFP for using VB
7000 WTFP for using PHP


VB and PHP are certainly RWTFs, but there's no way that they're worse than using Access.

Re: Source Control Done Right

2011-09-06 09:07 • by The poop... of DOOM! (unregistered)
359439 in reply to 359438
Paratus:
The poop... of DOOM!:
The "Real" WTF:

6000 - using ACCESS as a database


7000 WTFP for using VB
7000 WTFP for using PHP


VB and PHP are certainly RWTFs, but there's no way that they're worse than using Access.

He said using Access as a database, so you can combine that.

A PHP application calling an Access database would result in 13000 WTFP (and a developer who's been committed to a mental hospital)

Re: Source Control Done Right

2011-09-06 09:08 • by the beholder (unregistered)
Wait, what? The other universe's Alex is the Bizarro one??

Re: Source Control Done Right

2011-09-06 09:11 • by QJo (unregistered)
359441 in reply to 359437
The poop... of DOOM!:
The "Real" WTF:
mm...is it SourceSafe (who uses source safe??)

or is it writing an educational article about source control in a website dedicated to bad practices?

i think we're long overdue an article about WTF practices.
taken from select implementations on this website through the years and put together into one incoherent collection of WTF practices.

also - how about a WTF rating:
you often here people say "i worked on a really crappy system"
or "you wouldn't believe how bad the code here is"

but these claims are often not backed up due to "copyright" or "theft of source code" or something.
well - i have a solution:
WTF rating - a comparable scale of WTFP (WTF points).
the ratio tries to capture the level of WTFness (bugs, crashes, user complaints, complexity and incomprehensibility) introduced by each WTF.
Points accumulate, reflecting the fact that the larger the system the more WTFs you will find, and the worse off it is.

i.e.
1000 WTFP - Writing your own version of a bool (with that long missing 3rd option)
10 WTFP - giving a variable a meaningless name
20 WTFP - giving a variable an opposite name
50 WTFP - giving a variable an incomprehensible name (NotNonInvisible)

you can also give points to WTFP (WTF Practices)
i.e.
300 - Hiring experts that take months to write their own name in code
500 - Hiring cheap outsourceres that build you a crappy system and then paying 3 times the price to have it fixed
6000 - using ACCESS as a database
..

Finally we can award WTFP (WTF Prizes) to the system with the highest WTFP and WTFP.

7000 WTFP for using VB
7000 WTFP for using PHP


10^4 WTFP for storing passwords and other sensitive info in plaintext in a database and only thinking you've encoded them

2 x 10^4 WTFP for consistently releasing untested code changes to Production so as to save time assuaging the rage of the customer who's fallen foul of the last swathe of untested code changes that were released to Production

10^5 WTFP for balancing the mission-critical servers on the cistern in the women's bathroom of the office next door and/or frying your breakfast on the chassis of a similarly-deployed servers in the office kitchen

10^6 WTFP for dismissing your most capable staff for daring to suggest that your arse-brained scheme may need some further refinement, nay, even a redesign, before rushing ahead with implementation

10^7 WTFP for turning up at an interview for your perfect job wearing brown shoes

Re: Source Control Done Right

2011-09-06 09:15 • by QJo (unregistered)
359442 in reply to 359441
QJo:
The poop... of DOOM!:

7000 WTFP for using VB
7000 WTFP for using PHP


10^4 WTFP for storing passwords and other sensitive info in plaintext in a database and only thinking you've encoded them

2 x 10^4 WTFP for consistently releasing untested code changes to Production so as to save time assuaging the rage of the customer who's fallen foul of the last swathe of untested code changes that were released to Production

10^5 WTFP for balancing the mission-critical servers on the cistern in the women's bathroom of the office next door and/or frying your breakfast on the chassis of a similarly-deployed servers in the office kitchen

10^6 WTFP for dismissing your most capable staff for daring to suggest that your arse-brained scheme may need some further refinement, nay, even a redesign, before rushing ahead with implementation

10^7 WTFP for turning up at an interview for your perfect job wearing brown shoes


... and of course 10^9 WTFP for confusion of "its" and "it's" in a comment in a program module

Re: Source Control Done Right

2011-09-06 09:24 • by Anonymous Cow-Herd (unregistered)
359443 in reply to 359441
QJo:
10^7 WTFP for turning up at an interview for your perfect job wearing brown shoes

Pff, I once overslept on an interview day, and as a result arrived unwashed, unshaved, with an unironed shirt and shoes that had been dusted off rather than polished, and 20 minutes late. I got the job and started the following Monday.

Maybe Graham's number WTFP for using SourceSafe for anything other than to demonstrate to management that you're using it.

Re: Source Control Done Right

2011-09-06 09:28 • by The poop... of DOOM! (unregistered)
500 WTFP for having the only developer on the project write the tests after development, then having him run the tests and calling that QA (not to mention being surprised there're still bugs in the thing, as it's been tested!)

Re: Source Control Done Right

2011-09-06 09:38 • by L. (unregistered)
Over 9000 WTFP for using MySQL in a project where a database is really required.

And .. I strongly disagree with putting php (5+) on the same level as ASP . I believe we can safely assume WTFP(ASP/vb)=10*WTFP(php).

But if we're into the language bashing (which imo is not serious WTF .. except asp/vb/foxpro/cobol/...) why not go for a good old religion war and state the following:

if($language.creator=='microsoft'){$language.wtfp=nanotime();}

Why the tools matter.

2011-09-06 09:39 • by Sanity
First: The revised "Distributed" diagram is not the only way to set up a DVCS. It's by far the easiest, but certainly not the only way. It's also worth mentioning that for a typical project, a local Git repository is actually going to require less space than a Subversion checkout, so storage isn't relevant.

But there's more to it than that. Adding individual shelves to Subversion was the best and worst thing our team did. Best, because it meant that people were no longer afraid to check in for days at a time, not wanting to break the build with their experimental stuff, which only prolonged that experimental stuff due to them not being able to use version control the whole time.

Before this, we were all working off trunk, which has the additional issue that anytime a developer checks something in, they potentially create a merge conflict with someone else's working copy when they do an 'svn up'.

Worst, because Subversion completely fell over when we tried to use it that way. Especially when we added the merge tracking feature, which does make merges less likely to require manual intervention, but also made them take roughly half an hour. At that point, we were afraid to branch more than we had to, because merging would be painful -- but then, it's usually a given that merging is painful.

Git changed all that. After migrating the project to Git, those half-hour merges took seconds. Plus, we get backup for free, and we can work offline easily.

This is a valid concern:

"With the ease of forking, the simplicity of merging, and allure of pulling, it only seems logical to branch by shelf and end up picking up Jenga pieces."

But the real win isn't that each developer has a shelf, it's that even a feature which will take me only a few hours to develop can get its own branch. I can start work on a new feature without worrying that it'll interfere with anything else -- an urgent bug request could come in, and I'll just switch back to my 'master' or 'shelf' (or even 'trunk') branch and work from that, or create a new branch from the latest release if it's urgent enough to rush out a patch.

There's nothing inherently 'distributed' about any of the above. If non-distributed systems made it easy for a developer to create a new branch on the server, work on it for an hour, and then merge it in seconds, that'd be great. But making merging efficient and easy is a problem every DVCS has had to solve, much more so than a traditional SCM with a central server.

But the distributed pieces matter, too. As mentioned before, developer checkouts are now a sort of backup of your version history. I think it also helps that I'm in the habit of committing as soon as I have anything, which makes it a lot easier to keep commits small and to the point. The nice thing about a DVCS here is that I can easily roll back and re-commit that last change before I push it to anywhere publicly visible -- git's "--amend" option, for example -- so if I catch a typo or something minor before I push, I avoid a lot of "fixed typo" commits. This is even more useful with open source -- I can completely edit my commit history, rearranging things until it looks much more logical than it was, before I submit them for review.

For what it's worth, I also don't agree that every merge needs to be manually reviewed. If you've got a decent test suite, run that. Manual code reviews are useful, but they should be done independently of merges.

I can't really say I'm surprised. What would be surprising is if Alex ever admitted that a hot, new, over-hyped technology actually improved anything. But I have to say, there really are better and worse source control systems, and the new breed of DVCS is a huge improvement over systems like SVN.

Re: Source Control Done Right

2011-09-06 09:45 • by David C. (unregistered)
359448 in reply to 359430
QJo:
Documentation is usually written in Word (or using a similarly ill-maintainable program) so in a source-control system usually need to be stored in binary form. In such a form it may not be as easy to establish what the differences are between versions.
...
Another option is to use a wiki for the documentation.
Document control systems are usually optimized to deal with these problems. They generally understand the file formats involved (e.g. MS Office's various formats). While they may store each revision as a binary, they have features to take advantage of the file formats. For example, one system we use at work (sorry, I don't know who makes it - it might be an in-house system) has the following features:

* Stores metadata (document number, creator, revision, etc.) in MS Office document property fields.

* Automatically creates corporate-standard header/footer sections on all documents, making the metadata visible.

* Includes facilities for document approval, so managers can sign-off on released versions of a document, distinguishing it from works-in-progress.

* Automatic generation of PDFs from all supported document types (so people viewing files don't need to have the original app installed.)

These are things that are really useful (possibly even critical) for document storage, but would be mostly pointless when applied to source code.

Re: Source Control Done Right

2011-09-06 09:46 • by QJo (unregistered)
359449 in reply to 359443
Anonymous Cow-Herd:
QJo:
10^7 WTFP for turning up at an interview for your perfect job wearing brown shoes

Pff, I once overslept on an interview day, and as a result arrived unwashed, unshaved, with an unironed shirt and shoes that had been dusted off rather than polished, and 20 minutes late. I got the job and started the following Monday.

Maybe Graham's number WTFP for using SourceSafe for anything other than to demonstrate to management that you're using it.


Any advance on Grahams's Number! Who's first up for suggesting a particular WTF is worth Aleph-Null WTFP?

Re: Source Control Done Right

2011-09-06 09:49 • by Decoded (unregistered)
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110



10011001 00101100 01101111 11110000 11111001 11011110
11001101 00010010 10111000 01011101 11110111 10001101
10000101 11011111 01111000 11011001 10010010 11000110
10011001 00101100 01101111 11110000 11111001 11011110
11001101 00010010 10111000 01011101 11110111 10001101
10000101 11011111 01111000 11011001 10010010 11000110
10011001 00101100 01101111 11110000 11111001 11011110
11001101 00010010 10111000 01011101 11110111 10001101
10000101 11011111 01111000 11011001 10010010 11000110
10011001 00101100 01101111 11110000 11111001 11011110
11001101 00010010 10111000 01011101 11110111 10001101
10000101 11011111 01111000 11011001 10010010 11000110



153 44 111 240 249 222
205 18 184 93 247 141
133 223 120 217 146 198
153 44 111 240 249 222
205 18 184 93 247 141
133 223 120 217 146 198
153 44 111 240 249 222
205 18 184 93 247 141
133 223 120 217 146 198
153 44 111 240 249 222
205 18 184 93 247 141
133 223 120 217 146 198



™ , o ð ù Þ
Í  ¸ ] ÷ 
… ß x Ù ’ Æ
™ , o ð ù Þ
Í  ¸ ] ÷ 
… ß x Ù ’ Æ
™ , o ð ù Þ
Í  ¸ ] ÷ 
… ß x Ù ’ Æ
™ , o ð ù Þ
Í  ¸ ] ÷ 
… ß x Ù ’ Æ



I'm so very dissapointed.

~Nick~

Re: Why the tools matter.

2011-09-06 09:59 • by David C. (unregistered)
359451 in reply to 359447
The most important thing, IMO, about any VCS is its ability to make merges as painless as possible.

Many offer very little. They may generate diffs and point out conflicts, but they make you resolve even the most trivial of conflicts. When you've created a private branch/shelf and need to merge in others' changes without damaging your own edits, a good merge system is critical.

Unfortunately, most systems are very bad at this, and every free system I've used is included.

Without (hopefully) sounding like an advertisement, I've found that the commercial product, Perforce, is the only one that gets this right. The server tracks a file's entire revision history, through all of its permutations of branches (and there may be hundreds, for some key files belonging to large projects.) When you need to do a merge (which they call "integrate"), the system uses the version history to find the common ancestor between your file and the one you're merging in (even if this common ancestor is separated by dozens of intermediate branches.) It then does a 3-way diff on the files (yours, the one you're merging in, and the common ancestor), presenting all conflicts as all three versions of the conflicting lines. Sections where only one source (yours or the merged-in version) differ from the ancestor are automatically merged without any user intervention. (You can, of course, still review the merged changes and fix any mistakes, which still happen occasionally.)

With this system, you can actually merge any branch into any other branch, not just into direct parent/child branches. The server will track the operations and make the right thing happen, even if the branch/merge history starts looking like a tangled ball of rubber bands.

It's not a perfect system. You still sometimes have to manually merge files, but they manage to automate all of the easy situations, so you only have to manually merge the really nasty changes that no system is likely to be able to handle automatically.

(No, I don't work for Perforce, but my employer has used their product for many years and I'm very happy with it.)

Re: Source Control Done Right

2011-09-06 10:00 • by Poo (unregistered)
359452 in reply to 359422
Dave:
I've actually had the conversation about the difference between document management and source control before with co-workers. But I admit to not knowing what to use instead. Any suggestions?

Alfresco can be used for document management with versioning of documents.

Re: Why the tools matter.

2011-09-06 10:07 • by Poo (unregistered)
359453 in reply to 359451
David C.:
The most important thing, IMO, about any VCS is its ability to make merges as painless as possible.

Many offer very little. They may generate diffs and point out conflicts, but they make you resolve even the most trivial of conflicts. When you've created a private branch/shelf and need to merge in others' changes without damaging your own edits, a good merge system is critical.

Unfortunately, most systems are very bad at this, and every free system I've used is included.

Without (hopefully) sounding like an advertisement, I've found that the commercial product, Perforce, is the only one that gets this right. The server tracks a file's entire revision history, through all of its permutations of branches (and there may be hundreds, for some key files belonging to large projects.) When you need to do a merge (which they call "integrate"), the system uses the version history to find the common ancestor between your file and the one you're merging in (even if this common ancestor is separated by dozens of intermediate branches.) It then does a 3-way diff on the files (yours, the one you're merging in, and the common ancestor), presenting all conflicts as all three versions of the conflicting lines. Sections where only one source (yours or the merged-in version) differ from the ancestor are automatically merged without any user intervention. (You can, of course, still review the merged changes and fix any mistakes, which still happen occasionally.)

With this system, you can actually merge any branch into any other branch, not just into direct parent/child branches. The server will track the operations and make the right thing happen, even if the branch/merge history starts looking like a tangled ball of rubber bands.

It's not a perfect system. You still sometimes have to manually merge files, but they manage to automate all of the easy situations, so you only have to manually merge the really nasty changes that no system is likely to be able to handle automatically.

(No, I don't work for Perforce, but my employer has used their product for many years and I'm very happy with it.)


So, have you tried git?

Re: Source Control Done Right

2011-09-06 10:08 • by me (unregistered)
359454 in reply to 359430
QJo:
Documentation is usually written in Word (or using a similarly ill-maintainable program)

...and that, as they say, is the real WTF...

Re: Source Control Done Right

2011-09-06 10:22 • by QJo (unregistered)
359455 in reply to 359454
me:
QJo:
Documentation is usually written in Word (or using a similarly ill-maintainable program)

...and that, as they say, is the real WTF...

No argument against that point of view from me.

Re: Source Control Done Right

2011-09-06 10:23 • by egon (unregistered)
I tend to like distributed system more...

Local copy of repo is most useful when either the main server is down or you don't have network. You can't commit or switch / create / merge (working) branches or even see the logs, then what good is a source control system if you can't use it.

Also I've always thought "commit" and "push" as "commit" and "inflict". One just stores data, the other inflicts other people with it. This extra step means usually I think twice before sending stuff to main server.

Re: Source Control Done Right

2011-09-06 10:31 • by Hello (unregistered)
359457 in reply to 359427
QJo:

There was so much to do and the deadlines were so tight it resulted in me working on the average of 70 hour weeks (all overtime unpaid) and being denied any decent leave for 18 months. Surprise was expressed at my exit interview that one of the reasons I was leaving was that I was tired.


You had a choice, a choice to quit immediately when faced with 30 hours overtime each week. But you didn't and then you complain afterwards. Perhaps now you have learned to stick up for yourself.

Re: Source Control Done Right

2011-09-06 10:50 • by lyates
Thanks, Alex, for this back to basics SCM tutorial.
It's concise and very informative.

-Larry

Re: Source Control Done Right

2011-09-06 10:53 • by QJo (unregistered)
359459 in reply to 359457
Hello:
QJo:

There was so much to do and the deadlines were so tight it resulted in me working on the average of 70 hour weeks (all overtime unpaid) and being denied any decent leave for 18 months. Surprise was expressed at my exit interview that one of the reasons I was leaving was that I was tired.


You had a choice, a choice to quit immediately when faced with 30 hours overtime each week. But you didn't and then you complain afterwards. Perhaps now you have learned to stick up for yourself.


Good call. You're dead right, I should have jumped ship way before I did. But (a) I hadn't realised at the time how heavy it was going to be, (b) it took some time to find somewhere to jump to.

Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.

Re: Source Control Done Right

2011-09-06 11:06 • by The "Real" WTF (unregistered)
359460 in reply to 359446
L.:
Over 9000 WTFP for using MySQL in a project where a database is really required.

And .. I strongly disagree with putting php (5+) on the same level as ASP . I believe we can safely assume WTFP(ASP/vb)=10*WTFP(php).

But if we're into the language bashing (which imo is not serious WTF .. except asp/vb/foxpro/cobol/...) why not go for a good old religion war and state the following:

if($language.creator=='microsoft'){$language.wtfp=nanotime();}


I think most languages are not inherently WTFP worthy.

except for perl.

it may be the only "real" language who's 99 bottles code is somewhat similar looking to brainf*ck

oh and why is my comment spam?? what did i do wrong?

Re: Source Control Done Right

2011-09-06 11:24 • by ac (unregistered)
359462 in reply to 359459
QJo:
Good call. You're dead right, I should have jumped ship way before I did. But (a) I hadn't realised at the time how heavy it was going to be, (b) it took some time to find somewhere to jump to.

Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.


Bear in mind that doing a lot of work for free (e.g. 30 hours of overtime per week for 18 months > 2000 hours), your employers may already not think very highly of you. Sure, they'll think you're a hard working fellow and might recommend your new prospective employer makes references calls. However, they'll most likely laugh their asses off because you gave them so much work for free and soon forget that you ever existed. They most likely know very well that they're asking you to do 2 people's jobs for 1 salary. If you jump ship and drop all those "responsibilities and dependants" once you realize the task is totally unreasonable, it probably won't change what they think of you.

There's one thing I learned early on in my career, by looking at the people around me. Those who put in all that (unpaid) overtime for someone else leave a huge part of their life between four walls and get nothing but a nice reference call, if your new employer actually does call for references.

Re: Source Control Done Right

2011-09-06 11:24 • by trtrwtf (unregistered)
359463 in reply to 359430
QJo:

Documentation is usually written in Word (or using a similarly ill-maintainable program) so in a source-control system usually need to be stored in binary form. In such a form it may not be as easy to establish what the differences are between versions.


There is some documentation written in word, but it's hardly the industry standard. XML markup of various sorts (ie, docbook) is much more reasonable, since it can generate web and PDF and other forms. I believe all of the popular authoring systems are saved as flavors of XML.

Re: Source Control Done Right

2011-09-06 11:27 • by QJo (unregistered)
359464 in reply to 359460
The "Real" WTF:
L.:
Over 9000 WTFP for using MySQL in a project where a database is really required.

And .. I strongly disagree with putting php (5+) on the same level as ASP . I believe we can safely assume WTFP(ASP/vb)=10*WTFP(php).

But if we're into the language bashing (which imo is not serious WTF .. except asp/vb/foxpro/cobol/...) why not go for a good old religion war and state the following:

if($language.creator=='microsoft'){$language.wtfp=nanotime();}


I think most languages are not inherently WTFP worthy.

except for perl.

it may be the only "real" language who's 99 bottles code is somewhat similar looking to brainf*ck

oh and why is my comment spam?? what did i do wrong?


APL is arguably WTF-worthy.

Re: Source Control Done Right

2011-09-06 11:28 • by Dave (unregistered)
"The third – and the least used – special type of Fork operation is called Shelf."

From the point of view of the master repository of a large project, aren't most developer repositories and branches in a distributed system?

My branch of a project on GitHub will never be used to make a build of the official library for instance, so aside from my PoV (and perhaps others working with me) my repo/branch is a shelf.

Well, it'll never be used _directly_ to make an official build at least - if I submit a patch from my code that is accepted or the people with access to the master repo/branch otherwise chose to pull in some of my changes then my branch has an indirect effect on the "real" build. but as that indirect effect is gated by the mast repo's owners I'd say they are still in control of that and my copy is still a shelf from their PoV (and the PoV of the public at large if they use the library) by the definition in this article.

That would make the shelf a very common type of fork, rather than the least used one.

Re: Source Control Done Right

2011-09-06 11:41 • by Zetetic (unregistered)
359466 in reply to 359450
$ perl -ne 'chomp; print pack "B*", $_' <<END | ent -b

100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
100110010010110001101111111100001111100111011110
110011010001001010111000010111011111011110001101
100001011101111101111000110110011001001011000110
END
Entropy = 0.986040 bits per bit.

Optimum compression would reduce the size
of this 576 bit file by 1 percent.

Chi square distribution for 576 samples is 11.11, and randomly
would exceed this value 0.05 percent of the times.

Arithmetic mean value of data bits is 0.5694 (0.5 = random).
Monte Carlo value for Pi is 2.666666667 (error 15.12 percent).
Serial correlation coefficient is 0.036979 (totally uncorrelated = 0.0).

Re: Source Control Done Right

2011-09-06 12:17 • by blah (unregistered)
Of course, knowing how to merge doesn’t exactly help you understand why parallel repositories needing merging in the first place.
// Maybe I needing this

Re: Source Control Done Right

2011-09-06 12:38 • by RRDY (unregistered)
359468 in reply to 359462
ac:
QJo:
Good call. You're dead right, I should have jumped ship way before I did. But (a) I hadn't realised at the time how heavy it was going to be, (b) it took some time to find somewhere to jump to.

Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.


Bear in mind that doing a lot of work for free (e.g. 30 hours of overtime per week for 18 months > 2000 hours), your employers may already not think very highly of you. Sure, they'll think you're a hard working fellow and might recommend your new prospective employer makes references calls. However, they'll most likely laugh their asses off because you gave them so much work for free and soon forget that you ever existed. They most likely know very well that they're asking you to do 2 people's jobs for 1 salary. If you jump ship and drop all those "responsibilities and dependants" once you realize the task is totally unreasonable, it probably won't change what they think of you.

There's one thing I learned early on in my career, by looking at the people around me. Those who put in all that (unpaid) overtime for someone else leave a huge part of their life between four walls and get nothing but a nice reference call, if your new employer actually does call for references.


I don't think you understood what QJo meant be 'responsibilities and dependents'. Not the JOB responsiblities. Spouse and kids more likely.

Re: Source Control Done Right

2011-09-06 12:40 • by frits
359469 in reply to 359468
RRDY:
ac:
QJo:
Good call. You're dead right, I should have jumped ship way before I did. But (a) I hadn't realised at the time how heavy it was going to be, (b) it took some time to find somewhere to jump to.

Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.


Bear in mind that doing a lot of work for free (e.g. 30 hours of overtime per week for 18 months > 2000 hours), your employers may already not think very highly of you. Sure, they'll think you're a hard working fellow and might recommend your new prospective employer makes references calls. However, they'll most likely laugh their asses off because you gave them so much work for free and soon forget that you ever existed. They most likely know very well that they're asking you to do 2 people's jobs for 1 salary. If you jump ship and drop all those "responsibilities and dependants" once you realize the task is totally unreasonable, it probably won't change what they think of you.

There's one thing I learned early on in my career, by looking at the people around me. Those who put in all that (unpaid) overtime for someone else leave a huge part of their life between four walls and get nothing but a nice reference call, if your new employer actually does call for references.


I don't think you understood what QJo meant be 'responsibilities and dependents'. Not the JOB responsiblities. Spouse and kids more likely.

Exactly. Anyone who doesn't realize this is a n00b at life, or maybe a Forever Alone Guy.

Re: Source Control Done Right

2011-09-06 13:22 • by tomhanks (unregistered)
359473 in reply to 359430
QJo:
wva:
Why the hell would you want to keep documentation out of the source control system?

What makes a latex/org/... file different from a c/py/.. file? In both cases you want to track and merge changes and see who did what when, and branch as ideas are tried or different "stable" versions are needed...


Documentation is usually written in Word (or using a similarly ill-maintainable program) so in a source-control system usually need to be stored in binary form. In such a form it may not be as easy to establish what the differences are between versions.

If you're maintaining your documentation in e.g. TeX, then it may well be more appropriate to use a source-control system for the docs.

Another option is to use a wiki for the documentation.


trwtf is writing documentation in the first place

am i right?

Re: Source Control Done Right

2011-09-06 13:37 • by snoofle
359474 in reply to 359469
QJo:
30 hours weekly unpaid overtime for a long time
We've all done that early on in our careers. Once burned, twice shy. Once you learn to see it coming you can make for the exit long before you're exhausted (who wants to show up at a new job the first day - needing a vacation?)

It's the fools who keep doing it over and over that cause management to continue this practice of abusing and then discarding employees.

Re: Source Control Done Right

2011-09-06 13:52 • by Nagesh (unregistered)
I am not to be using sorce control for porpuses of incriminations.

Re: Source Control Done Right

2011-09-06 14:03 • by Smitty
359477 in reply to 359459

Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.


QFT.

Re: Source Control Done Right

2011-09-06 14:35 • by Part-time dev (unregistered)
I rather suspect that Alex doesn't understand distributed source control systems like Git and Mercurial.

Once you figure out how it actually works and stop thinking in terms of svn and SourceSafe then you start to realise why it really is the best way to work.

That's not surprising because it really doesn't actually behave the same way as traditional source control.

Joel Spolsky said a while ago “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

He later realised that he was totally wrong - http://www.joelonsoftware.com/items/2010/03/17.html

Alex seems to be making a similar mistake here.

One of the really key things I've found with Git is that you never have to 'check-out' a file and two people working on the same file is rarely an issue.

For example:

I'm told "Fix bug A", my colleague is told "Fix bug B".

We both need to work on the same file to fix these bugs for whatever reason. (Maybe it's WTF code, maybe not)

With git, we can both go ahead and do our bugfixes on our local repos, then push the changes to each other once we're each happy that our stuff is good.

If I'm slower than her, when I sync with her to merge in her changes (or a central server) I magically get her fixes - unless we both edit the same method, it Just Works.
- Much of the time it's fine as long as we haven't both edited the same exact line.

With VSS, if she gets to the repository before me then I can't do anything. In other ones, it's extremely easy for either of us to accidentally wipe out the other's work.
(Sync A, Sync B, Commit A, Commit B - A's commit just vanished!)

That's really annoying.

Distributed source control means that every single developer automatically has their own 'shelf' to work with, and that merging the shelves to make 'trunk' is usually quite easy.

As mentioned earlier, this also means devs are more likely to keep 'commits' down to very small, focused changes - which are much easier to deal with later on.

-Plus you can all keep working - including rollbacks, 'forks' and 'labelling' - when the network (or server) is down and know that it's not going to be painful to put it all together when the sysadmins get it fixed.

Re: Source Control Done Right

2011-09-06 14:35 • by annie the moose (unregistered)
You're doing it wrong!

C:\VersionControl
MyProg.201109060900.c
MyProg.201109060904.c
MyProg.201109060915.c


It's so easy.

Re: Source Control Done Right

2011-09-06 14:42 • by Abso
359481 in reply to 359479
Part-time dev:
With VSS, if she gets to the repository before me then I can't do anything. In other ones, it's extremely easy for either of us to accidentally wipe out the other's work.
(Sync A, Sync B, Commit A, Commit B - A's commit just vanished!)

That's really annoying.

VSS may be that much of a WTF, but that doesn't mean that every non-distributed source control system is. In this specific situation, even CVS will refuse to commit B's changes until B updates/syncs again.
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Add Comment