Hi guys
My team is currently new in using SVN. We were VSS babies before and are now trying to grow to SVN. I was wondering, since we have the whole project checked in, we are having a lot of problems with this kind of setup. I'd just like to ask what would be the best thing to do? Should we just check in the source files and not the whole project? Or is this totally fine? Thanks!
Convert limitations to great expectations... You are the creative force of your life...
Oh, just to clarify. When I said the whole project, in Java, this is the whole Eclipse project file(with the .project and .classpath extensions) and/or a project and solution file for .Net. Thanks!
Hi lamia,
I'm not sure about Java, but for .NET projects, it is customary to have the whole solution checked in, sans the generated files.
E.g., exclude the following from source control:
/bin folder + contents
/obj folder + contents
*.suo files
and everything else that changes regularly / e.g., log files, application generated files, user preference files, etc.
One thing that shocked me when I moved from VSS to SVN is the fact that there is no exclusive checkout in SVN. Two developers can edit the same file at the same time; if they are committed and there are no conflicts (e.g., neither dev edited a line edited by the other dev) a merge will occur. If there are conflicts, conflict resolution should be done manually, e.g., one person marks his file as resolved and then commits that file.
That's the better way of doing things, turns out, instead of the lock-out system of VSS.
Thanks LaTtEX,
Yeah, I think we should just go that way too. And yeah, it is a bit shocking not to be able to exlusively lock-out the file when you check-out. I guess I just got to get used to it. Got to begin removing those bin folders now...
LaTtEX:One thing that shocked me when I moved from VSS to SVN is the fact that there is no exclusive checkout in SVN. Two developers can edit the same file at the same time; if they are committed and there are no conflicts (e.g., neither dev edited a line edited by the other dev) a merge will occur. If there are conflicts, conflict resolution should be done manually, e.g., one person marks his file as resolved and then commits that file.
there is actually, but its not a default option.
i think it's entirely different in java, you can ask barakoboy here, he's a guru.
↑ Grab this Headline Animator
I just hope that he's reading this right now...
you can just email him through his blog if u have an urgent question
i think the only difference is for referencing projects/jar files, i was surprised last time when a java project in a previous company has their jar files checked in to source control. i think VS>eclipse with respect to handling references, they were not using maven btw that time.
in vs we can just have the source code organized in projects checked in without any output binaries and VS handles everything on build time, producing binaries for referenced projects.