
The 10 commandments of good source control management - hanszeir
http://www.troyhunt.com/2011/05/10-commandments-of-good-source-control.html
======
Xixi
_"10. Dependencies need a home too"_

I agree with this statement, but that home is definitely not with your code.
There are tools better suited for that. For instance nexus & maven.

Nexus store artifacts (which are really any piece of data: a jar, a tar.gz, a
zip file). That's where you put your dependencies. Maven manage a project's
build, that's where you tell what are your dependencies.

But really, there are many other tools out there to handle that (ant, nant,
pypi, etc.).

~~~
moe
It's funny to see someone defend Maven in 2011.

However, yes, checking in dependencies with your code is the way to go.

Deps that can be _reliably_ included with just a meta-descriptor (i.e.
Gemfile, pom.xml, etc.) are still exceptionally rare. Thus the natural choice
is to put the rest right next to the code that it belongs to. Well, natural
choice unless you're stuck in a 90s java mindset...

~~~
CodeMage
What's wrong with Maven? I'm asking this as someone who hasn't used it and who
wanted to give it a whirl. Any input would be much appreciated.

~~~
gchpaco
If you want to do something simple it takes a 60 line pom.xml to express it.
If you want to do something a little trickier it takes another 60 lines and
three hours minimum of poking around at inadequately written docs. If you want
to do something difficult, forget it. Ant, which is a nightmare of usability
and continues to make me wake in the middle of the night screaming, is at
least as complex to configure, better documented and is not a quarter as
constrained as Maven.

That said the Maven dependency model isn't too bad; fortunately you don't have
to adopt Maven to get it, you can just use Ivy.

------
Luyt
_"In all fairness, VSS was a great tool."_

I disagree. Even back in 1995 it had fatal flaws. More than once it got so
confused that we had to restore the source tree from backup. There was also
the continual problem of files being locked by others when they should not
have been, hampering progress and complexities. I was glad when we could kick
it out of the door.

~~~
sid0
I'm pretty lucky I got old enough to use version control _after_ fast,
reliable and easy-to-use tools like git and hg were created. Every time I have
to interact with a CVS repository I'm like "wow, people actually used to use
this everyday".

~~~
pnathan
Heh, I remember when I used CVS. It was for a senior project. I didn't really
get what CVS was, and it was such a pain-

I slammed all the files in the day before and handed them in all at rev 1.
Cranky prof.

------
b0sk
I gave a skim and didn't find this

11\. Never commit revisions which can't be built. (In the exceptional cases,
always state in the commit message that the code doesn't build.)

~~~
bnegreve
This. is wrong. One should be able to commit every little meaningful change he
has made, with a equally meaningful commit message. If you wait until
everything works you'll end with huge meaningless conflicting commits. Of
course it is quite annoying if you use a centralized SCM since everything you
commit becomes public. Well this is actually why you should not use
centralized SCM.

~~~
masklinn
> One should be able to commit every little meaningful change he has made,
> with a equally meaningful commit message.

If your commit is broken, it's not meaningful, it's just broken.

> If you wait until everything works you'll end with huge meaningless
> conflicting commits.

Reading comprehension, please. b0sk talked about commits which _can not be
built_. It's a very clear and simple requirement and it definitely does not
mean _is not feature-complete_.

> Of course it is quite annoying if you use a centralized SCM since everything
> you commit becomes public. Well this is actually why you should not use
> centralized SCM.

There really is no relation, and a DVCS will not save you when an axe-murderer
with a short temper tries to bisect a bug, and you break his bisection because
your commits made the whole project un-buildable.

~~~
gcr
Let's try this again. Speaking as a git user, my workflow is a little
different.

> If your commit is broken, it's not meaningful, it's just broken.

Sometimes I make broken commits just to have something for the written record.
Sometimes I rebase them away. Sometimes I ask friends to pull from a broken
commit (gasp!) when I need their help to fix my bug. Often times I 'git commit
--amend' to fix broken commits before I push. In any case, there's no reason
to artificially hide these mistakes as long as the result works.

> There really is no relation, and a DVCS will not save you when an axe-
> murderer with a short temper tries to bisect a bug, and you break his
> bisection because your commits made the whole project un-buildable.

Git allows you to automatically skip untestable commits. See
[http://www.kernel.org/pub/software/scm/git/docs/git-
bisect.h...](http://www.kernel.org/pub/software/scm/git/docs/git-
bisect.html#_bisect_run)

In my workflow, I usually use a 'master' branch and 'topic' branches. The
master must always build, as you say. Topic branches don't -- they're
experimental by definition. When a topic is ready to go, we rebase and clean
up the commits. This way, we get a traceable, ever-buildable source tree from
master and experimental branches when we want them.

Problem?

------
sigil
_7\. Versioning your database isn’t optional_

He's talking about versioning schema, not data -- he should have been clearer
about this.

~~~
alok-g
Where does he say that. I think he <i>is</i> talking about versioning data
(and schema as well).

~~~
sigil
I had to dig for it, but he references another article he wrote [1] which
says:

 _There is never a reason to use source control to version your data_ _This
will be painfully obvious to most people, but I’ve seen it done before, and
more than once too. Source control management exists to version, um, source
code..._

[1] [http://www.troyhunt.com/2010/07/rocking-your-sql-source-
cont...](http://www.troyhunt.com/2010/07/rocking-your-sql-source-control-
world.html)

------
mhb
What is a good tool for version control of a Postgres database on an Ubuntu
server?

------
TorKlingberg
This seems to assume that everyone is committing into the same branch. How
about the workflow where you create a new branch for each work package and
merge it into the main branch when finished? It lets you check in to your own
branch as often as you want (even broken code) without worrying about breaking
anything for the other devs. The merges will be bigger though, days or weeks
of work. A good point is that the branch merge is a natural time to look
through all the diffs.

------
DCoder
_Compilation output does not belong in source control_

I've seen this before, but never found a suitable alternative. Where does it
belong? Suppose multiple developers are compiling a C++ .dll which testers are
grabbing through websvn and testing. To track down crashes they get, we need
the associated .pdb for the right revision. Where should these files be kept?
In a plain folder where each revision gets its own subfolder named as the
revision number? That means updating two separate locations with each build,
using two different interfaces...

~~~
masklinn
> Suppose multiple developers are compiling a C++ .dll which testers are
> grabbing through websvn and testing.

The DLL is a compilation output, it's not to be in source control.

> To track down crashes they get, we need the associated .pdb for the right
> revision. Where should these files be kept?

To track down crashes they need the DLL to start with.

Testers should either have the ability to build the project on their machine,
or they should be able to grab the output from the CI server (just go to the
CI server, open the latest correct (compiled, tested, green) revision, grab
files from there and test that.

~~~
sliverstorm
_The DLL is a compilation output, it's not to be in source control._

Mmm... I've been working in a medium-sized group project, and we've been
having pretty good luck with source controlling our driver .lib file. The
intermediate object files are discarded, but it's really nice not needing to
recompile the library every time somebody updates the library code.

(This is a 'project' that produces a library rather than an executable, for
inclusion into other 'projects')

~~~
StrawberryFrog
What you want is a CI server that does a build after every checkin and keeps a
copy of the output file.

------
parody_error
"6. You must commit your own changes - you can’t delegate it"

My company does this, and I'm not entirely sure how I feel about this. The
motivation for delegating changes is that different groups in our company have
different check-in priveleges. This results in half of my changes being
committed by me and half the changes being committed by someone else. This
does, of course, present some coordination problems though.

------
sliverstorm
_subsequent commit messages from the same author should never be identical_

I violate this one sometimes. I'm not a VCS magician, so sometimes I get
commit errors, and wind up having to make a second commit. I figure identical
commit messages makes it pretty obvious the two commits were intended to be
one.

~~~
joelhaasnoot
git commit --amend

~~~
mikle
Not everyone is using git. I know that the cool kids all do, but some of us
still use svn.

~~~
joelhaasnoot
See this as another reason you should look into switching. The concept of
branches that work well is revolutionary to your workflow.

~~~
Zev
The most useful thing that git has given my workflow is `git stash`. I almost
never find myself branching and absolutely hate having to push, pull and pick
changes between separate branches.

------
grendel
I keep all dependencies in ivy (.Net/C++ shop). If I don't need to hack the
source it goes in ivy.

~~~
yock
I know this is a tangent and that this story isn't about dependency
management, but it's important to me and I've spent a good amount of time
trying to understand it completely.

I spent what I thought to be a generous amount of time trying to wrap my head
around Ivy and I just couldn't make it work the way I thought it should work.
I use Maven, and while I'm not a Maven...er...maven, I can work with it well
enough and I'm certainly adept with its dependency management mechanisms. Ivy
just seems to have way too many moving pieces and their documentation always
seems to be missing key pieces of information that link theory to example. I'm
left with an incomplete understanding of how Ivy works and, as a result, I
can't use it effectively.

