Source control redux
-
Mike Lang wrote:
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
But now one person can make fixes to the ABS functionality while another is fixing another method. This is great with common routines where the methods are probably static and used throughout the application(s). Since doing this and looking at the changes in 3.0, this will be replaced with extension methods. :-D
WarePhreak Programmers are tools to convert caffiene to code.
Ware@Work wrote:
But now one person can make fixes to the ABS functionality while another is fixing another method.
I think this is the point with two features in most source control systems; auto-merge and non-exclusive checkouts. Two developers can work on two different methods in the same file, and both can check in their changes without having to manually merge the files. Off Topic:
Ware@Work wrote:
this will be replaced with extension methods.
Hopefully people aren't planning to make every method an extension method with no methods in the actual class. That would just be too hard for most developers to understand.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
Douglas Troy wrote:
VSS 6.0d is the last release of this product; now it's that Team Server thing (I know nothing about it)
Actually, that's not true. VSS 2005 was released with VS 2005. It's not a HUGE difference from VSS 6, but it seems to be more stable, and offers some extra remote features (web checkin/out). http://msdn2.microsoft.com/en-us/vstudio/aa718670.aspx[^] Also, there's SourceOffsite that lets you use VSS client/server and make remote access much easier. I recommend *NEVER* using VSS remotely under normal conditions, there's too much risk for database damage if you do. 99.9% of peoples problems with SourceSafe database damage is related to trying to use it over flaky networking, IMO.
-- Where are we going? And why am I in this handbasket?
I think the question of source control, is mostly dependant on scale. Single Developer has the most options... If you are in a multiple developer project, you simply must use source control. If you have people scattered about the world, then VSS is likely not the best tool. (I have to admit that SVN is a much better choice than VSS for Hundreds of developers, scattered from Indiana to Mumbai.) In a small shop, its first about personal preference, then features. In a small shop, you might be the network admin, all the way to the bottle washer... the last thing you need is an Apache server for SVN, or a Square peg install of SVN on Win2K3. However, in a large professional effort, you need something more powerful, and its really no argument that SVN is a good choice over VSS. I dont agree that SVN is in any way "easier" than VSS. It's not easier to setup, its not easier to maintain, and in my humble experience I did not find it easier to use, if you consider VSS sits right inside the IDE.
Where there's smoke, there's a Blue Screen of death.
-
Ware@Work wrote:
But now one person can make fixes to the ABS functionality while another is fixing another method.
I think this is the point with two features in most source control systems; auto-merge and non-exclusive checkouts. Two developers can work on two different methods in the same file, and both can check in their changes without having to manually merge the files. Off Topic:
Ware@Work wrote:
this will be replaced with extension methods.
Hopefully people aren't planning to make every method an extension method with no methods in the actual class. That would just be too hard for most developers to understand.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
That's true, but I haven't (yet) used one that does that, so I'd be nervous about whether or not it merged properly... but that's just me. On the other hand, in an organization which doesn't have a really solid coding style standard, maybe the two developers have different styles; brace placement, indenting, etc. If each tells VS to format the file his way, then the whole file will be affected, and won't that complicate things? I expect part of the check-in process could be to run the file through a company-standard beautify routine. At any rate, this leads to a question about modern CVS VCS systems... can they be set up to ignore whitespace or otherwise reduce the effects of "style"?
-
I think the question of source control, is mostly dependant on scale. Single Developer has the most options... If you are in a multiple developer project, you simply must use source control. If you have people scattered about the world, then VSS is likely not the best tool. (I have to admit that SVN is a much better choice than VSS for Hundreds of developers, scattered from Indiana to Mumbai.) In a small shop, its first about personal preference, then features. In a small shop, you might be the network admin, all the way to the bottle washer... the last thing you need is an Apache server for SVN, or a Square peg install of SVN on Win2K3. However, in a large professional effort, you need something more powerful, and its really no argument that SVN is a good choice over VSS. I dont agree that SVN is in any way "easier" than VSS. It's not easier to setup, its not easier to maintain, and in my humble experience I did not find it easier to use, if you consider VSS sits right inside the IDE.
Where there's smoke, there's a Blue Screen of death.
DumpsterJuice wrote:
developers, scattered from Indiana to Mumbai.)
I know a few who should be. :-D
-
That's true, but I haven't (yet) used one that does that, so I'd be nervous about whether or not it merged properly... but that's just me. On the other hand, in an organization which doesn't have a really solid coding style standard, maybe the two developers have different styles; brace placement, indenting, etc. If each tells VS to format the file his way, then the whole file will be affected, and won't that complicate things? I expect part of the check-in process could be to run the file through a company-standard beautify routine. At any rate, this leads to a question about modern CVS VCS systems... can they be set up to ignore whitespace or otherwise reduce the effects of "style"?
PIEBALDconsult wrote:
At any rate, this leads to a question about modern CVS VCS systems... can they be set up to ignore whitespace or otherwise reduce the effects of "style"?
It was (IIRC) hidden in a config file, but there was an option to ignore whitespace in clearcase. I don't recall seeing any option for more theological style issues like brace placement.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
DumpsterJuice wrote:
I like my source control IN the IDE, ..not in Explorer thank you very much....
You probably know this already, but for the benefit of others, there are options for this with Subversion. At our office we use AnkhSVN http://ankhsvn.tigris.org[^] as a plugin within Visual Studio. I bet there are others as well. Not that I'm advocating you switch to Subversion. Our shop uses both Subversion and VSS and we've had no problem with either for as long as I've been here. BDF
Big Daddy Farang wrote:
Our shop uses both Subversion and VSS and we've had no problem with either for as long as I've been here.
Were you able to integrate both into VS at the same time, or only one of them?
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
Big Daddy Farang wrote:
Our shop uses both Subversion and VSS and we've had no problem with either for as long as I've been here.
Were you able to integrate both into VS at the same time, or only one of them?
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
No, both at the same time would be way too cool for us. :laugh: We have some older stuff that's in VSS. Out of that stuff there's one product that I still support in good old native VC++ 6. Our bigger C# products, and I think all of our Linux stuff is kept in Subversion. So I've got the Tortoise thing for Explorer and Ankh plugin for VS 2003 (currently.) BDF
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
I don't know exactly what qualifies as "little hassle as possible", but let me plug Git. I'm using it on Windows and it's absolutely easy for the scenario you just described above. First, I'm a seasoned Subversion user. I like it and think it's great, but it's forgetfulness when merging from branches to the trunk have always been a sore point (though this item will be fixed in 1.5.0). Also, I've never cared for having to have specific server software for it, whether it be the Apache mod or its standalone server. If the server was down, you're hosed. Last, I don't care for the .svn directories all over the place. But as I said, it's about the best thing there is. Then I had a fellow dev recommend git. I thought at first it was just a Linux thing, and I'm a Windows guy, so I didn't put much credence into it. Then I saw him demo how the merging and branching worked, and how fast it was, and I was sold. Another great thing is that by virtue of its distributed model, it's easy to push a copy of your repository up through an HTTP server for others without requiring special server software. Lastly, it only has a single .git directory that's a breeze to backup and/or cleanup. However, all is not panacea. Git doesn't have great Windows integration with tools. There is no Visual Studio Git plugin, nor is there anything like TortoiseSVN (a great tool BTW). However, I don't mind, but that might be a deal breaker for you. It does have GUIs, but I haven't tried them. It's CLI is more than sufficient for me. In short, here are the pros and cons of Git over SVN as I see them: Pros: 1) Git is small and fast. 2) It's very easy to backup and doesn't leave .svn droppings 3) It doesn't need any server software because it's a "distributed" source code control system, which also makes it easy to put your code up on the web. 4) git can import and export to svn repositories with git-svn Cons: 1) It has a strong linux heritage, though that is slowly being overcome. 2) Tool integration is not. The GUIs look a bit amateurish from what I've seen, though this too is changing. The web interface though does look pretty good. 3) Subversion does have momentum. Things like Trac are great. Again, I'm not advocating ditching svn. It's great, and I continue to use it for some things, but git is fast gaining my mindshare. Jay -- modified at 15:05 Saturday 22nd September, 2007
-
No, both at the same time would be way too cool for us. :laugh: We have some older stuff that's in VSS. Out of that stuff there's one product that I still support in good old native VC++ 6. Our bigger C# products, and I think all of our Linux stuff is kept in Subversion. So I've got the Tortoise thing for Explorer and Ankh plugin for VS 2003 (currently.) BDF
Big Daddy Farang wrote:
No, both at the same time would be way too cool for us.
*Sigh* I was hoping you were cleverer than I and had managed to figure out how to do it.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
That's true, but I haven't (yet) used one that does that, so I'd be nervous about whether or not it merged properly... but that's just me. On the other hand, in an organization which doesn't have a really solid coding style standard, maybe the two developers have different styles; brace placement, indenting, etc. If each tells VS to format the file his way, then the whole file will be affected, and won't that complicate things? I expect part of the check-in process could be to run the file through a company-standard beautify routine. At any rate, this leads to a question about modern CVS VCS systems... can they be set up to ignore whitespace or otherwise reduce the effects of "style"?
It is smart enough to recognize the difference between whitespace in a string definition vs whitespace between code statements. If you want to see how good the diff tool is, you can use that independently of the source control. This is a free tool. http://www.sourcegear.com/diffmerge/index.html[^] I compared these class files to verify my assertions:
namespace DiffTest { public class SomeClass { public string myField_ = "some string"; } }namespace DiffTest{ public class SomeClass{ public string myField_ = "some string"; } }It highlighted the extra space in the string literal as a 'significant difference', but not the extra space before the equal sign. To reproduce these results, ensure you select menu item "View->Hide unimportant differences". The UI shows the lines with curly braces are different, but not with the significant difference color. The way the tool does this is there are rulesets configured per file extension type. However, If you don't like the sourcegear diff tool, you can configure vault to use another diff tool. http://download.sourcegear.com/misc/sos/help/externalprograms1.htm[^] (I don't work for or benefit from sourcegear for these statements. I just like the tools.)Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
It is smart enough to recognize the difference between whitespace in a string definition vs whitespace between code statements. If you want to see how good the diff tool is, you can use that independently of the source control. This is a free tool. http://www.sourcegear.com/diffmerge/index.html[^] I compared these class files to verify my assertions:
namespace DiffTest { public class SomeClass { public string myField_ = "some string"; } }namespace DiffTest{ public class SomeClass{ public string myField_ = "some string"; } }It highlighted the extra space in the string literal as a 'significant difference', but not the extra space before the equal sign. To reproduce these results, ensure you select menu item "View->Hide unimportant differences". The UI shows the lines with curly braces are different, but not with the significant difference color. The way the tool does this is there are rulesets configured per file extension type. However, If you don't like the sourcegear diff tool, you can configure vault to use another diff tool. http://download.sourcegear.com/misc/sos/help/externalprograms1.htm[^] (I don't work for or benefit from sourcegear for these statements. I just like the tools.)Michael Lang (versat1474) http://www.xquisoft.com/[^]
Excellent, thanks.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
Hi John, I have worked with TFS (Team Foundation Server), which is a Microsoft production. It was quite strong in branching and taking care of the branches (fixing bugs and patching them back into previous releases while adding new features into the up-coming release). I would recommend it. It is by far better and more reliable than VSS, the other Microsoft source control. The other benefit of TFS is, as far as its core database is SQL server, not only you have the scalability of the db engine, you can also run your own queries to extract some special information out of the data. Cheers, Mehrbod
-
Why CVS Sucks[^] CVS Sucks[^] Bye Bye CVS. I've been Subverted[^]
-- Where are we going? And why am I in this handbasket?
I still use cvs in windows mainly for the client. wincvs is better than any other client I have tested in windows. As for moving files and folders. On the rare occasion I want to do that (move or rename a file) I manually do it on the server by copying/moving the files.
John