views:

1217

answers:

7

Say I'm working on a project and I know that I've completed a specific class and that it should not be edited again, ever. How can I lock this class so no more commits on it can happen? I've tried locking it, but that only lasts one commit and still allows me to edit it.


Reasoning:
I have a class that performs one thing, and one thing only. It manages X part of the database. X will not change, therefor the class will not have to change. Any changes could be hazardous and introduce bugs which are not necessary. For sake of example this is one class in a project containing a googol (1.0 x 10^100) of classes. Branching for one minor class would be overly complicated, especially if half the classes were like this, you'd wind up with half a googol branches, at least.

+6  A: 

Create a branch of your entire project - then you can merge future changes from your trunk as and when you want to deploy them.

Paul Dixon
But the project isn't read to branch, it's only one class that is totally and completely finished (actually is several but for the example, say it's one class out of 2,000 that's finished and won't be touched again)
Malfist
ok, so branch 1 only has one finished class. branch 2 will have 100 finished classes. You probably *will* change your one class, and by looking at the diffs between branch 1 and branch 2, you can see what was done and why
Paul Dixon
+6  A: 

EDIT:

Based on your edit, if you know it won't change, then why even worry about it? If you don't trust your developers then there is some other problem, but from what I can see you are trying to use version control to "solve" something that is not really there.

I, and I assume many others, are very suspicious about the "no changing" assertion.

Just leave it the way it is.

two other options are pre-commit hooks or access control via the permissions file.

POST PRIOR TO EDIT:

If you are using apache for the repository you can set the permissions to read only fr that file(s). But in my opinion this is a big mistake.

For your builds you can just force a particular revision in the "get"?

Create a branch and enforce that as the one to use all the time.

If you add commit hook notifications you can be made aware of changes to your files that you do not want.

Alternatively you can have a development branch and the "approved" branch and just never promote any changes to that file(s)

Tim
+2  A: 

Well, to start with, the basic answer is you don't know that a particular class should never ever be edited again. Believe me, it will be.

That said, a code freeze -- where you say "no more changes" -- is easily implemented in svn by pulling a tag or a branch (the difference is pretty arbitrary) on the code.

If you want to freeze one file, consider using an svn property to tag it.

Charlie Martin
+1  A: 

Typically Source Control Systems don't allow you to permanently lock classes. That makes sense, since if you have a bug, you'd have to "unfreeze" the class, etc.

Subversion allows you to either tag or to branch your code, however. Tagging allows you to get back to a specific version of your code, and branching allows you to work on multiple versions of your program at the same time. Both allow you to "freeze" code in a way.

On large projects, before freezing a release, you typically will branch from HEAD, and continue putting in bug fixes into the branch (say v1)- that provides isolation from any new development that's going into HEAD for V2.

Jean Barmash
+4  A: 

You might be able to use a pre-commit hook that rejects changes to specific files under specific conditions.

http://svnbook.red-bean.com/en/1.2/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Nzbuu
I agree. Just reject a commit that has the file. If (when) you find you need to edit that file you can remove the hook.
WaldenL
+2  A: 

I wouldn't use source control for this, instead if you can extract a chunk of functionality (including this class) then you could create a separate project from that. The output of that project could then be included as a library in your main project, ie in Java I'd create a jar from the new project and included that in my main project. If/when this class and it's associated classes change you can recreate the library, but would have full control over when you decide to include those changes into your main project.

Robin
A: 

You can use the SVN lock feature, but instead of locking it with your own user name, use a specific user account (e.g. "ice-code" (pun intended)) to take the lock. This way, when you commit, it won't try to release the lock. When you want to release all the locks, use the separate user account to unlock it.

Garo Yeriazarian