Comments on: 5 sins of subversion usage http://blog.cherouvim.com/5-sins-of-subversion-usage/ software engineering for beginners Wed, 07 Jan 2009 17:01:30 +0000 http://wordpress.org/?v=2.5 By: ounos http://blog.cherouvim.com/5-sins-of-subversion-usage/#comment-929 ounos Sun, 30 Sep 2007 19:19:43 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-929 /nbproject is actually required, unless you have a custom build script which is imported instead. Otherwise, how would one compile from the console? And how would one ensure that there is one standard build process (so not to allow much potential for the "works for me" syndrome)? Typically what is not needed is /nbproject/private (and causes problems, as it hardcodes file paths). /nbproject is actually required, unless you have a custom build script which is imported instead. Otherwise, how would one compile from the console? And how would one ensure that there is one standard build process (so not to allow much potential for the “works for me” syndrome)?

Typically what is not needed is /nbproject/private (and causes problems, as it hardcodes file paths).

]]> By: cherouvim http://blog.cherouvim.com/5-sins-of-subversion-usage/#comment-460 cherouvim Fri, 18 May 2007 16:31:51 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-460 Yes. They are for developers. But I just meant that sometimes the repo might be shared by other, less technical, people. Yes. They are for developers. But I just meant that sometimes the repo might be shared by other, less technical, people.

]]> By: papo http://blog.cherouvim.com/5-sins-of-subversion-usage/#comment-457 papo Fri, 18 May 2007 13:26:24 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-457 your points above are for developers not....graphic designers...right? so ...yes when it comes to developers ..they should stick to the recommended structure.or a strict defined structure known to the whole team .instead of sending multiple emails saying...Ooohhh yes by the way now you should download version from /aproj/thisversion/blabla . your 'In any case' scenario is NOT acceptable IMHO. your points above are for developers not….graphic designers…right? so …yes when it comes to developers ..they should stick to the recommended structure.or a strict defined structure known to the whole team

.instead of sending multiple emails saying…Ooohhh yes by the way now you should download version from /aproj/thisversion/blabla . your ‘In any case’ scenario is NOT acceptable IMHO.

]]> By: cherouvim http://blog.cherouvim.com/5-sins-of-subversion-usage/#comment-456 cherouvim Fri, 18 May 2007 04:51:25 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-456 Yes, you are right. The SVN structure above displayed the paths up to the root of each individual project. Note though, that an SVN repo might not be used exclusively by programmers. Graphic designers might import static html/css templates in their own project folders. Enforcing this policy to them might not be for the faint hearted (no disrespect here). In any case, SVN, gives you the flexibility to work in any way you like. And when things get really messy, you can start renaming and moving things around. Then you simply send mails with the new locations where everyone can svn switch their working copies :) Yes, you are right.

The SVN structure above displayed the paths up to the root of each individual project.

Note though, that an SVN repo might not be used exclusively by programmers. Graphic designers might import static html/css templates in their own project folders. Enforcing this policy to them might not be for the faint hearted (no disrespect here).

In any case, SVN, gives you the flexibility to work in any way you like.
And when things get really messy, you can start renaming and moving things around. Then you simply send mails with the new locations where everyone can svn switch their working copies :)

]]> By: papo http://blog.cherouvim.com/5-sins-of-subversion-usage/#comment-452 papo Thu, 17 May 2007 09:10:06 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-452 I would also suggest the following. Adopt the SVN suggested repository project structure. such as /trunk /branches /tags . Develope in trunk do branches and tag the final releases. Everyone must be comfortable with the notion of the three of them. Checking out appropriate any of them or merging back to the tree! Do not import any project before creating such a project structure in the SVn repository! I would also suggest the following. Adopt the SVN suggested repository project structure. such as /trunk
/branches /tags . Develope in trunk do branches and tag the final releases. Everyone must be comfortable with the notion of the three of them. Checking out appropriate any of them or merging back to the tree!
Do not import any project before creating such a project structure in the SVn repository!

]]>