 |
 | General Comments 
Thursday, June 5, 2003 1:09 AM
|
|
|
If you have some general comments about the project, please post them here 
Any comments are welcome...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
I am so glad someone else sees a need here for a better multiuser bug tracker and version control software than we have with SourceSafe without having to turn our Windows machines into Unix boxes to use CVS. Plus the CVS documentation is horible in trying to setup a Windows machine.
I've been looking at Subversion (which is trying to make a better version of CVS) but it's hard to get it to compile on Windows (plus you have to turn your box into Unix to actually do the compile) so I've started working on my own design trying to make a better version control software with integrated issue tracking.
So let me just give you my ideas so we can get the discussion rolling.
1. The version constrol software (VCS) should store it's information in a database and allow the interoperability with different vendor's databases. I would like to see at a minimum a SQL Server and a MySQL implementation.
2. Should be client/server from the start. CVS wasn't designed with client/server in mind and has way too many usage for the CVSROOT. It must have 4 different meaning. Subversion uses WebDAV/Delta-V HTTP extensions but I think that this is the older way to solve problems. I think the newer way would be with Web Services to allow the service to be consumed over the internet.
There should be different web services to manage the different aspects of the VCS. So there should be a service for Administration, Development, Issue Tracking and maybe Project Management if it grows to be big enough.
These web services could then be consumed by a client side project that would either integrate with VS.Net, Stand Alone app or Explorer Extension.
3. Should allow easy branching of the source code. This is where I think CVS/Subversion did it right compared to how difficult/confusing this concept is in SourceSafe.
4. Take advantage of the Windows operating system and be made to show off these strength instead of writing to the lowest common denominator so that the code is multiplatform. This means writing any services that we may have to use, or the EventLog.
5. I would like to see it integrate with the VS.Net interface but I think we have to get a NDA from MS for the SCCI interface. Maybe this could be a subproject that is not release with the rest of the project.
6. Issuetracking should be a feature rich as BugZilla but made to run on Windows using a backend database as it's storage mechanism.
7. I would like to see an integration between the VCS and the IssueTracker so that issues could be tied to checkins into the VCS.
Well that's about all that I can think of at the moment and I look forward to hearing other peoples' comments and suggestions.
|
|
|
|
|
|
|
I love your ideas, I'll take a closer look tomorrow, as I'm kinda busy today...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
I've been doing some more digging/reading and here is how I see it.
The Version Control Software (VCS) is structured as a n-tier application with it broken up into at least 3 tiers. Database tier, Services tier and User tier. There maybe another tier that would be added in the future to support background processing such as emailing notifications, generating reports or something else that I haven't thought of.
Database Tier
The database services should support storing of the file data and the meta data in a relations database management system (RDBMS) such as SQL Server, Oracle, MySQL or PostgresSQL. This would not lock anyone into having a specific vendor of database that they have to have installed but at a minimum it should work with SQL Server/MSDE since we are writing this with a Windows focus.
User Tier
The user tier should have services that allow the tool to be included into the DevStudio SCC interface, a Windows Explorer shell extension or a command line tool. By covering all three options we give the devolopers a choice in what they feel is the most useful to the way that they work.
To support these different tiers we should make a client side library that all these different tools use to access the VCS but the tool just has to provide the specific interface to integrate with it's targeted environment. This means for Visual Studio integration it should support the SCC interface and make use of the client library to interact with the middle tier. The Windows Explorer Shell Extension should implement all the interfaces necessary for a shell extension but also take advantage of the client side library for communication with the middle tier.
If we are going to use a web services model (which I think we should ) the latest release of ATL has support for doing SOAP calls and getting WebRequest and WebResponses just like C# does without having to used the managed C++ extensions. I will be happy to go into more detail on this if you like but I really see this as a big win and a good way to learn some of the newer ATL stuff.
Services Tier
This is the most difficult piece of the project to implement and which way do we go about it. Do we just create web services by using the ATL Server classes and expose the middle tier as a series of web services or do we write our own service from scratch.
The problem I see with writing our own service is that it makes it more difficult to get access through a corporate firewall if we are trying to do remote checkin/checkouts of the VCS. If we take advantage of the newer technologies that are in the pipeline such as WebServices it gives us a way to work on some cool new technology that we may not be able to with our current jobs and by using the HTTP protocol through SOAP calls we allow the VCS to be more easily used in a corporate environment that may have their firewall configured to turn off a lot of ports except port 80.
Along this lines of writing an web service in the latest release of ATL there is a whole new series of classes for writing high performance server applications that integreate themselves with IIS as the old way to do ISAPI extensions but this time they can written as XML Web Services.
This looks to be a very exciting project and I would like to make the best VCS software available for the Windows OS taking advantage of all that Windows has to offer without writing to the lowest common denominator so that the code will compile on Unix. Unix already has plenty of good VCS tool available for it but to use them with Windows is hard or you end up making your Windows machine into a Unix box just to use these tools.
|
|
|
|
| |
|
| What languages do we use to make this product
Thursday, June 5, 2003 12:07 AM
|
|
|
I can see the use for a few different languages.
The Source Control Server in Native C++
The Source Control Client in Winforms
The defect Tracker Client in ASP.NET
Any other ideas?
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
I'd prefer any WinForms or ASP.NET application being developed in C#.
Greetings,
heinz r. vahlbruch
c++ & c# programmer from germany
If IntelliSense doesn't have it, it ain't worth calling - Anonymous
My compiler compiled yours - Seen on a VC++.Net T-Shirt
|
|
|
|
|
|
|
Same here. C# it is, for Winforms and ASP.NET 
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
I'd like to see the Defect Tracker Client in Winforms and ASP.net.
Also, is it reasonable to write the service for the Source Control Server in MC++. Susposidly it is the "prefered" way MS wants us to write Services?
Hey don't worry, I can handle it. I took something. I can see things no one else can see. Why are you dressed like that?
- Jack Burton
|
|
|
|
|
|
|
Chris Austin wrote:
I'd like to see the Defect Tracker Client in Winforms and ASP.net.
Same here, written in C#
Chris Austin wrote:
Also, is it reasonable to write the service for the Source Control Server in MC++. Susposidly it is the "prefered" way MS wants us to write Services?
Hmmmm, I would like the server to be written in native C++, and maybe a bit of MC++ if it needs to talk to managed code...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
Well I know *insert unspeakable language here* and C#. Also know the ASP.NET environment well enough.
What will be the storage provider? SQL? The idea mentioned earlier about supporting multiple storage providers (SQL, MySQL, Oracle etc.) is nice but I wonder how feasible (and useful) it will be for us to implement. Also a big part of your idea is Source Control and Defect Tracking for Microsoft/Windows developers (Windows Apps, ASP, ASP.NET etc.)
How many MS developers use or have MySQL? I only have it because once a year we get a project that has PHP and MySQL in it. The rest of the time it sits dormant on the server.
And I have no idea about C++, native or managed
Paul Watson
Bluegrass
Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
|
|
Paul Watson wrote:
*insert unspeakable language here*
Paul Watson wrote:
What will be the storage provider? SQL?
I'd prefer MS SQL as primary database.
Paul Watson wrote:
And I have no idea about C++, native or managed
Well, I'd like to improve my knowledge in MC++ and I think ther server apps might be implemented in it.
Greetings,
heinz r. vahlbruch
c++ & c# programmer from germany
If IntelliSense doesn't have it, it ain't worth calling - Anonymous
My compiler compiled yours - Seen on a VC++.Net T-Shirt
|
|
|
|
|
|
|
If you are interested we are going to use all your knowledge in both C# and ASP.NET
I tend to agree with you on the database choice, but if we make all the dataconnections in a seperate class (module) it can alwayt be changes to work with another database. Like Oracle, it sucks but is used a lot on wWindows....
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
Well i have yet to get involved with this project but i would like to toss an idea ( well more like experience ) in if I may. I don't know if anyone here has every looked at/used SourceGear's Vault source control but I have and can tell you that while .NET is tempting you should be carefull about certain performance penalties that may arise. We recently bought and switched to their vault software which is written using various .NET technologies ( for those of your who don't know it uses a SQL server backend ) and the performance of the overall system is rather sluggish in my opinion. I have always wanted to jump in a design a good Source Control System but never had the time ( until now? ) . So maybe i will be the outcast here but i would say that those involved should also given some consideration to languages with solid background in speed such as C++.
Well, thats just my 2 cents. If i want to get on board this project is there somewhere i need to signup? Message board?, email link?, something?
Thanks.
Joseph Dempsey
joseph_r_dempsey@yahoo.com
"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."
--anonymous
|
|
|
|
|
|
|
Right now, I think we'll have team member sign-up on the actual article that gets created (on the message board). This will probably happen soon after project leaders submit a draft abstract to me.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
|
|
Let me add my two cents into this discussion.
Given the real-world transactional volume that a SCC system usually has to deal with (even in a large organization), I don't think the choice between C++, MC++, or C# is really going to have a substantial impact on performance of the server component. Most of the heavy lifting should be done in the database using stored procedures to begin with. Even for databases that do not support stored procedures, the SQL execution happens within the database, and so I would expect most of the bottleneck to exist there. Performance will depend a great deal on solid relational database design practices. Lastly, if language performance ever does become an issue, then at that point I think we should look to refactor the components that are responsible for a bottlneck into platform specific implementations (C++, etc).
Second, if we are developing an OSS system, it really should be runnable on a wide cross-section of different databases. I don't think someone should have to purchase SQLServer or Oracle (both expensive DBs) just to run a _free_ SCC system! We should strive to partition the data layer using the interface/implementation pattern so that different providers could be developed and plugged into the core system when desired. Ideally, any system that supports ANSI SQL should be a target for such a system.
I'll also throw out another thought, and that is that we should try to develop the server-side component of the system as a web service. By doing so, we open the door for both non-Windows client implementations and non-Windows server implementations. What we should really design/control is the XML dialect that will be used to initiate SCC transactions, searches, and management operations. By doing so, we will really divorce the interface between the client and server from any platform, technology, or language -- thereby creating substantially more flexibility and broaden the appeal of the tool. It will also make the SCC system accessible through a firewall through HTTP -- this is a big deal where you want to put a SCC system up on the Internet and make it both secure AND accessible. .NET makes development of web services ridiculously easy -- and it would be a shame to pass up an opportunity to use this technology in a way in which it is intended to be used.
“Try to learn something about everything and everything about something.” - T. H. Huxley (English Biologist)
|
|
|
|
| |
|
| What would you want to see in a new Source Control System
Thursday, June 5, 2003 12:04 AM
|
|
|
Just post your ideas
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
How about these folks?
- SCM Provider for VS
- Branches
- Tags
- Version History
- Special inline tags like CVS and P4 to quickly see who made the last change/commit
- TCP/SSL
Hey don't worry, I can handle it. I took something. I can see things no one else can see. Why are you dressed like that?
- Jack Burton
|
|
|
|
|
|
|
Nice
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
He he he. I get to bother other PL's!
SourceForge makes a big stink about security in their CVS system. I personally think that's all it is--a stinking pile of media driven drivel geared to scare the crap (hence the stench) out of management which of course mandates security in its operations upon us more knowledgable programmers.
So. Am I just naive? Are ya' gonna' implement security?
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
|
|
Marc Clifton wrote:
So. Am I just naive? Are ya' gonna' implement security?
No and Yes.
I have worked a lot with security, and you can bet that I think it's one of the most important features.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
1. Simple mode. I run a small shop and frankly roots, trunks, branches and twiglets confuse the hell out of me. I am sure for something like Mozilla all of that is neccesary, but when you are working on a project with at most two other guys and the project is pretty straightforward all one wants is the guarantee of your co-worker not editing a file while you are and rollback to a previous version. Really the bits I would use are Checkout/Checkin, Set Version and Rollback. CVS is abysmal for my needs. Source Safe when setup right is okish.
2. Looking forward I see the defect tracker and this SCC as being part of the PMS project. Part of that is a client facing aspect of the SCC. I want to be able to say "Bob, you can find the Alpha Test version of the files on the PMS console." Bob can then logon to PMS and there will be a simple button that says "Download latest version" and he can then download and install the application. Then Bob can come back to PMS, enter the Defect Tracker and add some issue items and these are connected to the latest version of the code.
Also there is often a need to package up all the source code and send it to another developer. At the moment that normally involves me zipping up a folder in WWWROOT, backing up a SQL database and then emailing it to him, all the time hoping that I sent him the latest files and that any unfinished items I am working on in the project do not break his copy. It would be much better if he could logon, click "Download latest source" and then he is a for away.
Remember that not everyone will be able to, or want to, use our SCC system. So there needs to be simple ways of "exporting" the source and detaching it completely from the SCC.
3. Documentation for a project should also be versioned and controlled. So Documentation Set 1.1 for Source Set 1.1 etc.
4. I really love your idea of linking defects to source. Not sure how this would work but it would be nice to ba able to link a defect to a specific (set of)/file(s) of code. So Joe double clicks the defect assigned to him to fix and it loads up in VS.NET the file that the defect most likely is in. e.g. If the bug is tagged as being a data layer bug then it links to datalayer.cs or whatever. This could be a bit hard to figure out though, how does the defect tracker know where in the code the bug most likely is? In all my bug reports I have an "Area/Location" column which says "Client Manager" or "Shopping Basket" or "Product View." The defect tracker user knows where he was in the system when he encountered the bug, so he can type in the Area/Location. Then in the SCC we could asssign files to certain Areas/Locations. Just an idea, might prove unworkable
5. Did I mention simple mode?
Paul Watson
Bluegrass
Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
|
|
Good ideas Paul, thanks
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
Some thoughts in no particular priority:
1) Client/server architecture with a database backend for repository.
Using a cheap (as in "free") db backend.
2) Multiuser capability, without locking files.
Merging/conflict resolution should be done on checkin if necessary.
2) Atomic commits (aka transactions)
3) Jobs/changelists (like Perforce's)
"Jobs" for tracking state of new features and bugs.
"Changelists" to change the state of "Jobs".
This actually goes into the bug-tracker part...
4) Disconnected workmode.
Some operations, like diff, should be able to work even though you're not connected to the server. (SubVersion does this).
5) "Security"
Fine-grained control over users permissions, i.e. per project/file control over each developers access rights.
6) LAN+WAN accessibility.
7) Simple and fast to use and setup.
8) Integration with Windows Explorer, i.e. TortoiseXXX shell extension.
9) Integration with various DevStudio's
10) Commandline tools.
Depending on the direction that the project takes I may be interested in participating... For now just count me in, then we'll see
Michael.
|
|
|
|
|
|
|
You have some good ideas, thanks
mbh@ito wrote:
For now just count me in, then we'll see
Will do, but soon the project get it's own article, then people can "sign in" to help...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
|
|
All of the above and a "plug-and-play" installation package for it all so that users who don't want to compile and configure everything themselves can run it right out of the box so to speak.
Also we need to pay attention to UI details. We use PVCS where I work and the graphics, et. al suck to say the most. The list controls flicker and the rest of the controls are ancient. We should also have a consistent icon/graphics scheme. Remember, no matter how good the code is, the user wants a simple and asthetically pleasing interface.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin