I'm in a discussion with a friend about how you use a version control system. In this particular case SVN. He seems to think that it's OK to use certain parts of the SVN directory structure to check in files he's not sure will compile. In other words experimenting directly in the version control directories.

In my world you never check anything into a a version control system you're not already sure is working. You use your IDE to verify that everything works and #then# you check it in.

He uses the TFM to argue in favour of his actions. Intuitively though, it makes little sense to me.

Short of RTFM can anyone tell me if my intuition is correct?

Regards,
Soren


Edit: Sorry. We Danes are per definition a little slow on the uptake.

I don't have a lot of experience with subversion. I do use git quite a bit. I usually create a separate branch for testing changes. I even keep separate branches to track remote git repositories of similar code bases. That way it is easier to roll back changes without making the commit log dirty. It makes it very simple by deleting the branch locally. I almost never upload testing or temporary branches to my remote git server where I have full access.

1 members found this post helpful.

dsl_: you are correct for SVN.

What mralk said is true for git, Mercurial, and other things that are better than SVN.

That is why everyone has switched to git.

1 members found this post helpful.

deleted.

Does not compute.

I would note that SVN encodes branches as directories (i.e., to make a branch in SVN, you copy your code to a new directory).

I’d say that code outside of trunk does not need to be correct similarly to how code outside of master branch (and all other release branches) doesn’t have to be correct in a git repository.

How else would you do a review? You need to share your code with others and that code isn’t necessarily its final version. Or you could have just a simple proof of concept which demonstrates an idea. Than again, I actually don’t know how you do reviews in Subversion.

With git though, once you’re ready to merge the branch you can rebase and play around with it to clean up the history such that each commit in the branch does compile and then merge that into master. I don’t know how that looks in Subversion.

I could accept the idea of having branches for experimentation, but I'm talking about the very branch that supposedly contains the working version.

That, I find a little weird.

Regards

you might want to put code into a version control system for different reasons: for example just to save it. You do not need to rely [only] on your on linux. Or because you want to share it with your staff.
But there is no general way of working, so you cannot have a common, global solution. It always depend on the team, the job and the other tools used.

On svn? You're supposed to generate a patch with "svn diff" and have that reviewed.