Comments on: Inline SCM: A Proposal For A Better SVN or Git http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/ a developer blog Sun, 07 Mar 2010 06:17:16 -0800 http://wordpress.org/?v=2.9 hourly 1 By: baraniii http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/#comment-3538 baraniii Mon, 01 Mar 2010 02:57:25 +0000 http://dbachrach.com/blog/?p=580#comment-3538 hello camila here.how are you.?oh very serious and boring issue you are talking about and right now i want to relax because these days i am busy doing preparation for <a href="http://www.securitypluspapers.com" rel="nofollow">security+ practice test</a>.oh its really very interesting. hello camila here.how are you.?oh very serious and boring issue you are talking about and right now i want to relax because these days i am busy doing preparation for security+ practice test.oh its really very interesting.

]]> By: Guest http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/#comment-3118 Guest Fri, 05 Jun 2009 22:41:39 +0000 http://dbachrach.com/blog/?p=580#comment-3118 Interactive rebasing in git solves your problem. Interactive rebasing in git solves your problem.

]]> By: Guest http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/#comment-3495 Guest Fri, 05 Jun 2009 22:41:39 +0000 http://dbachrach.com/blog/?p=580#comment-3495 Interactive rebasing in git solves your problem. Interactive rebasing in git solves your problem.

]]> By: Jason Skicewicz http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/#comment-3092 Jason Skicewicz Thu, 04 Jun 2009 18:35:53 +0000 http://dbachrach.com/blog/?p=580#comment-3092 This is a very interesting idea, and is very similar to an idea I had at one point that had to do with carving up the useful parts of the web, and attaching notes to blocks of web content. Its similar in that it is carving up the web at a finer granularity than bookmarks, which is what inline SCM is doing for source control. I think the usefulness would far outweigh how tedious it may become, and would encourage smaller commits, which is useful in its own right. I personally, check the diff on every file before I commit code to the repository to 1) come up with a descriptive commit message, and 2) to make sure I did not leave any debug code in what I am about to commit. So this whole process of looking at every block of changed code, would work extremely well in my workflow since I do it anyway.<br><br>I thought I would point out that your example is not exactly valid, although it is the way that many teams work. In a team that is following good process, all new features are developed in an entirely different branch, and are pulled in to your release branch as they are finalized / wanted / requested by biz. This way, the main branch, which is usually the trunk, only contains bug fixes and any approved features that were pulled in (nothing is developed in the main branch). I think what happened to the project that you are referencing, is that new features were developed in the main release branch. This should never be the case. The reason this happened, is because it was felt that these features would never be stripped out of the product, and would be present in the next release. A very bad assumption. This idea is very interesting because no teams (or very few) follow good version control practice. I mean, just take a look at how useful commit messages are on most projects.<br><br>In any case, this is a very good idea. One that I would love to help you build out =). You could easily build this on top of subversion or git without rewriting anything by essentially creating a markup language in the commit message itself. Sort of like the way InterTrac does it. This is a very interesting idea, and is very similar to an idea I had at one point that had to do with carving up the useful parts of the web, and attaching notes to blocks of web content. Its similar in that it is carving up the web at a finer granularity than bookmarks, which is what inline SCM is doing for source control. I think the usefulness would far outweigh how tedious it may become, and would encourage smaller commits, which is useful in its own right. I personally, check the diff on every file before I commit code to the repository to 1) come up with a descriptive commit message, and 2) to make sure I did not leave any debug code in what I am about to commit. So this whole process of looking at every block of changed code, would work extremely well in my workflow since I do it anyway.

I thought I would point out that your example is not exactly valid, although it is the way that many teams work. In a team that is following good process, all new features are developed in an entirely different branch, and are pulled in to your release branch as they are finalized / wanted / requested by biz. This way, the main branch, which is usually the trunk, only contains bug fixes and any approved features that were pulled in (nothing is developed in the main branch). I think what happened to the project that you are referencing, is that new features were developed in the main release branch. This should never be the case. The reason this happened, is because it was felt that these features would never be stripped out of the product, and would be present in the next release. A very bad assumption. This idea is very interesting because no teams (or very few) follow good version control practice. I mean, just take a look at how useful commit messages are on most projects.

In any case, this is a very good idea. One that I would love to help you build out =). You could easily build this on top of subversion or git without rewriting anything by essentially creating a markup language in the commit message itself. Sort of like the way InterTrac does it.

]]> By: Jason Skicewicz http://dbachrach.com/blog/2009/06/inline-scm-a-proposal-for-a-better-svn-or-git/#comment-3494 Jason Skicewicz Thu, 04 Jun 2009 18:35:53 +0000 http://dbachrach.com/blog/?p=580#comment-3494 This is a very interesting idea, and is very similar to an idea I had at one point that had to do with carving up the useful parts of the web, and attaching notes to blocks of web content. Its similar in that it is carving up the web at a finer granularity than bookmarks, which is what inline SCM is doing for source control. I think the usefulness would far outweigh how tedious it may become, and would encourage smaller commits, which is useful in its own right. I personally, check the diff on every file before I commit code to the repository to 1) come up with a descriptive commit message, and 2) to make sure I did not leave any debug code in what I am about to commit. So this whole process of looking at every block of changed code, would work extremely well in my workflow since I do it anyway.<br><br>I thought I would point out that your example is not exactly valid, although it is the way that many teams work. In a team that is following good process, all new features are developed in an entirely different branch, and are pulled in to your release branch as they are finalized / wanted / requested by biz. This way, the main branch, which is usually the trunk, only contains bug fixes and any approved features that were pulled in (nothing is developed in the main branch). I think what happened to the project that you are referencing, is that new features were developed in the main release branch. This should never be the case. The reason this happened, is because it was felt that these features would never be stripped out of the product, and would be present in the next release. A very bad assumption. This idea is very interesting because no teams (or very few) follow good version control practice. I mean, just take a look at how useful commit messages are on most projects.<br><br>In any case, this is a very good idea. One that I would love to help you build out =). You could easily build this on top of subversion or git without rewriting anything by essentially creating a markup language in the commit message itself. Sort of like the way InterTrac does it. This is a very interesting idea, and is very similar to an idea I had at one point that had to do with carving up the useful parts of the web, and attaching notes to blocks of web content. Its similar in that it is carving up the web at a finer granularity than bookmarks, which is what inline SCM is doing for source control. I think the usefulness would far outweigh how tedious it may become, and would encourage smaller commits, which is useful in its own right. I personally, check the diff on every file before I commit code to the repository to 1) come up with a descriptive commit message, and 2) to make sure I did not leave any debug code in what I am about to commit. So this whole process of looking at every block of changed code, would work extremely well in my workflow since I do it anyway.

I thought I would point out that your example is not exactly valid, although it is the way that many teams work. In a team that is following good process, all new features are developed in an entirely different branch, and are pulled in to your release branch as they are finalized / wanted / requested by biz. This way, the main branch, which is usually the trunk, only contains bug fixes and any approved features that were pulled in (nothing is developed in the main branch). I think what happened to the project that you are referencing, is that new features were developed in the main release branch. This should never be the case. The reason this happened, is because it was felt that these features would never be stripped out of the product, and would be present in the next release. A very bad assumption. This idea is very interesting because no teams (or very few) follow good version control practice. I mean, just take a look at how useful commit messages are on most projects.

In any case, this is a very good idea. One that I would love to help you build out =). You could easily build this on top of subversion or git without rewriting anything by essentially creating a markup language in the commit message itself. Sort of like the way InterTrac does it.

]]>