tag:blogger.com,1999:blog-9620948.post6424349699343453217..comments2023-10-20T12:24:17.734-07:00Comments on Binstock on Software: A Limitation in Subversion. Any ideas?Andrew Binstockhttp://www.blogger.com/profile/16321156191558412680noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-9620948.post-26998645724698765552009-01-23T13:52:00.000-08:002009-01-23T13:52:00.000-08:00@Adrian: Thanks for your thoughtful comment. I hav...@Adrian: Thanks for your thoughtful comment. I have come to the same conclusion you did; namely, that for the specific need I identified using a DVCS is a very workable solution.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-9343155196071657182009-01-23T03:01:00.000-08:002009-01-23T03:01:00.000-08:00The answer is a distributed version control system...The answer is a distributed version control system, because what you need is a "feature branch". Branching in SVN is cheap and quick, but the merging can be very painful. Branching in a DVCS is just as cheap, but the merging is much nicer. DVCS also allow you to make local commits, work offline, and are generally a lot faster than SVN.<BR/><BR/>There are several DVCS systems that will work with Subversion, so you don't have to migrate your central server just yet.<BR/><BR/><A HREF="http://svk.bestpractical.com/" REL="nofollow">SVK</A> is probably the most "native". This uses a Subversion repository as backing storage, and can push and merge revisions to a normal SVN repo. It suffers a little from being slow.<BR/><BR/><A HREF="http://git-scm.com/" REL="nofollow">git</A> is the real speed demon of the DVCS world, and can interact with SVN repos via the git-svn component.<BR/><BR/><A HREF="http://bazaar-vcs.org/" REL="nofollow">Bazaar</A> also has good support for SVN repositories via the bzr-svn plugin. Bazaar arguably has the best support for Windows of the three big next-generation DVCS systems, and being written (mostly) in Python makes it easier to scratch your own itches, should you have them. Not as fast as git, but still fast enough for the majority of projects and, like git and Mercurial, much faster than SVN. <BR/><BR/>Bazaar ended up being my choice for a project involving the merging of multiple simultaneous lines of development over some 4000 files. Mercurial has an edge case that my working tree ran into, and git was too scary for my end-users to contemplate.<BR/><BR/>Users make multiple commits into their working branches but at the end of the day are expected to commit a single working "merge" revision to the trunk which doesn't break anything.Adrianhttps://www.blogger.com/profile/14247304785101612656noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-60706266129749313852008-02-27T22:26:00.000-08:002008-02-27T22:26:00.000-08:00So I'm wondering if I missed it or you didn't say ...So I'm wondering if I missed it or you didn't say which IDE you use... Eclipse does it's own local file revision storage. I won't go so far as to suggest it can 'label' your entire set of files in that local repository, but I wouldn't put it past some eager eclipse plugin genius to come up with a way to do that.<BR/><BR/>hth. D.Dennis Nagelhttps://www.blogger.com/profile/08583902362791155599noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-49496868871888959012007-07-17T08:28:00.000-07:002007-07-17T08:28:00.000-07:00On the commercial side, this would also be easy in...On the commercial side, this would also be easy in AccuRev.<BR/><BR/>I'm still using Subversion, but am looking at experimenting with darcs or git in the future.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-73099284494863429482007-07-16T03:15:00.000-07:002007-07-16T03:15:00.000-07:00I think you've hit a a limitation of all centraliz...I think you've hit a a limitation of all centralized SCM systems. Decentralized SCMs are becoming popular of late, perhaps you could look into one of those (e.g. Mercurial, git, darcs or Bazaar). They are designed to handle exactly this use case, along with many others that cannot be handled by centralized systems.<BR/><BR/>However if you really have to use Subversion, then a branch with an appropriate do_not_use label is probably the only solution.Neil Bartletthttps://www.blogger.com/profile/08588098030811273044noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-66674203851020732562007-07-15T12:46:00.000-07:002007-07-15T12:46:00.000-07:00If you have lots of untested code, it probably mea...If you have lots of untested code, it probably means that you're development cycles are too long and you're not breaking things down into small enough pieces of code. My suggestion is to focus on smaller pieces of unit-testable code, and more frequent check-ins. If you use Mylar, it will automatically associate bugzilla, trac, or jira issues with your code whenever you perform your checkins. This will make it easier to find all code associated with a given issue. Especially if you have people collaborating on the same task. <BR/><BR/>Depending on your project philosophy, you can either declare that the HEAD is always "somewhat" unstable and that individual release branches are the points of stability in the project or create a separate branch for development builds.Unknownhttps://www.blogger.com/profile/11914656195894071907noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-27034337516616517472007-07-14T21:03:00.000-07:002007-07-14T21:03:00.000-07:00Matt: Thanks for your comment. Subversion does not...Matt: Thanks for your comment. Subversion does not have this concept, as such. Surround SCM would be an option, if it were not for the fact that I must use Subversion for the public OSS repository.<BR/><BR/>Brian: I think you're right. I should just use a branch that makes it clear the code must not be used. Thanks for the link and the solution, which is probably the best way to get around this limitation. <BR/><BR/>Odd that the CollabNet folks have not fixed this.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-12280010181243012582007-07-13T13:23:00.000-07:002007-07-13T13:23:00.000-07:00I think you just have to use a branch for this sin...I think you just have to use a branch for this since there is no native construct in SVN. It's a topic that comes up with MS Team Foundation developers since it has a feature called shelving...<BR/><BR/>It's worth reading some of these links...<BR/><BR/>http://www.google.com/search?hl=en&q=shelving+with+subversion&btnG=Google+Search<BR/><BR/>I's say non-working code in a repository is OK as long as it's not being pulled down for automated builds. It's a bigger problem if the trunk has non-working code. For most people creating a private branch and keeping a copy of code there is a good idea in case their machine dies.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-51602849505022563772007-07-13T05:59:00.000-07:002007-07-13T05:59:00.000-07:00Does Subversion support the concept of 'private' o...Does Subversion support the concept of 'private' or 'sandbox' branches? With Surround SCM for example, you can create what's called a Workspace branch which is private to a user. Developers can continually commit code to that branch w/o affecting the QA or production builds. Then merge code changes up as they bring the code into compliance with existing tests and/or create new ones. Since a user can't see any other user's Workspace, there's no potential for mixups as to what code to use.Anonymousnoreply@blogger.com