Comments on: 5 sins of subversion usage http://blog.cherouvim.com/5-sins-of-subversion-usage/ software engineering for beginners Mon, 23 Jan 2012 06:17:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Rob Church http://blog.cherouvim.com/5-sins-of-subversion-usage/comment-page-1/#comment-4587 Rob Church Thu, 30 Dec 2010 23:37:16 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-4587 Committing individual files one at a time, so that changesets are no longer atomic. This may or may not be detected even in a continuous integration environment; I caught this recently only by chance observation of a coworker who was checking in. It breaks one of the benefits of SVN, and it makes manipulating individual changes as "sets" harder than needed. Committing individual files one at a time, so that changesets are no longer atomic. This may or may not be detected even in a continuous integration environment; I caught this recently only by chance observation of a coworker who was checking in.

It breaks one of the benefits of SVN, and it makes manipulating individual changes as “sets” harder than needed.

]]> By: John conrad http://blog.cherouvim.com/5-sins-of-subversion-usage/comment-page-1/#comment-1136 John conrad Sun, 12 Jul 2009 08:51:03 +0000 http://blog.cherouvim.com/the-5-sins-of-subversion-usage/#comment-1136 one more nice topic in your blog and nice comments too keep it up, If you advise some more related links to topic. I'm very interested in CMS and all its related subjects. one more nice topic in your blog and nice comments too keep it up, If you advise some more related links to topic. I’m very interested in CMS and all its related subjects.

]]> By: ounos http://blog.cherouvim.com/5-sins-of-subversion-usage/comment-page-1/#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-page-1/#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-page-1/#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-page-1/#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-page-1/#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!

]]>