Source code control feature requests?

Viewing diffs between two versions, change lists, merging two versions together as long as there are no collisions, revert checked out file to previous version. These are few of the things I can think of that I use everyday. BTW, I use Perforce so I'd recommend checking that out and looking at its features. I think it's a pretty good system.



-SirKnight

Got to agree with SirKnight. You could do much worse than basically copying the Perforce feature set. The only thing I'd really add is a way to directly do renames and moves instead of doing it sideways via integrations. Hm, and the ability to add directories to the depot as well as files would be handy occasionally. Or at least a way to sync and only get the next level directories and not thier contents.

Good support for branching and the ability to integrate changes between branches is a must. Bonus points for very-large scale branching. I want to be able to create 10000 mini-branches off the main branch, one for every feature basically.

Not to be mean or anything, but you do realize that writing even a remotely decent source control system is hard? Large teams have spent several years on such projects and still not gotten close to a decent feature set.

Quote:

Original post by BeanDog I'm trying to do a good, solid, secure job with this project, so I have something real to show for it (and I'm planning on using this program myself).

Might I suggest that this is a bad plan?

I don't want to discourage you, because the fact you've gotten started and got some results is really great. I just don't think it would work very well.

You're not likely to have all that much to "show" for it. Unlike some kinds of applications, if you're showing a source-code-repository program to someone, they'll have a very good idea of what source control system is like, and unfortunatly unless you're freekishly good on your first attempt, you won't be up to the standard of commercial and freeware source control systems.

And on the subject of using it yourself, I'll suggest you'll be far better off with a prepackaged soultion. You'll be getting a known-solid program with support of some kind or another, without having to put huge ammounts of your own effort into it. Also, I personally wouldn't want to risk my code to a home-brew version control system, even if I knew it was solid.


As for features, I'm going to assume you've looked at the feature sets of at least Subversion, so there isn't all that much to offer that isn't minor technical detail (another reason why this isn't a great "show off" project). If you look at their mailing list, you can read about various important features they're still working on like built-in merge tracking and real renames.


Perhaps a better solution would be a C#/Windows Service frontend to Subversion? If I were apprasing projects, I'd probably be more impressed by the ability to effectivly build on other software, than a less-than-rock-solid peice of version control software (of course, your own software might be more solid, but that takes a great effort). A programmers time is really too valuable to go reinventing wheels, I'm afraid.

By "something to show for it," I didn't mean I was going to be bringing this to a job interview :-) I just meant that I would feel that I had accomplished something of a fair scale in this new environment rather than a mocked-up exercise in the back of a "21 days" book. Thus I could feel comfortable telling people, "I really know how to use C#."

I'm not intending to sell this project, I'm just going to spend several weeks of spare time getting it to a usable level and keep it around for my own hobby use. I'm not going to use it on any commercial projects, nor will it be my sole method of backups for my personal projects.

I don't want a flame war. I just want some suggestions for functionality that would be a stretch for me to implement :-)

Have a good day!



~BenDilts( void );

Don't worry - I have no interest in getting into a flamewar. As long as you understand the limitations of what you're attempting, then all is well. It is most certianly an unusual beginners project.

It's very good to see that you're chalanging yourself. Your selected task would be very low on my list of possible tasks for the beginner C# programmer, that's all [grin]. Keep up the good work.


I'd need to know your current feature list, and know a bit more about your programming ability to suggest a suitable feature. Some useful ones, if you havn't done them already, are: directory-structure versioning, log searching functions, or perhaps remote access.

An interesting one could be statistics generation. For instance - number of commits per day, or per person. One interesting statistic would be number of lines changed per day/person - it would use the data available from a versioning system to great effect. You could probably use some C#-fu to interface Excel to make pretty graphs.

Quote:

Original post by Andrew Russell I'd need to know your current feature list, and know a bit more about your programming ability to suggest a suitable feature. Some useful ones, if you havn't done them already, are: directory-structure versioning, log searching functions, or perhaps remote access.

The current feature list is pretty sparse:
File-level checkout/checkin.
Retrieve any older version of a file.
File-level and project-level versioning.
Mapping of repository project root folders to local hard-drive folders

My system was developed from the beginning with remote access in mind. I'm using standard .NET TCP/IP sockets and a homebrew protocol to connect any client (including one one localhost) to the repository server.

I'm by no means a new programmer (I've been programming about 10 years, with about 2-3 years of professional experience), but I'm new to C# and I'm new to the internal workings of source-code control and versioning systems. So I'm learning a few new things in one go.

Thanks for the response!



~BenDilts( void );

My personal dream feature in a revision system would be a way to have it tell me all of the files tied to a particular incident/bug. That way when someone has resolved a bug, then I would be able to know right away all of the files that were modified, which version, and which "release" it was a part of.

Maybe also if you can do something like clearcase, where each "stream" allows you to see the overall evolution of a file, I think the stream idea is meant for a project where you will have a lot of variation in functionality (like a frontend), and more traditional branching structures like CVS are better in the case where you want to have a main branch at all times that things get merged back into as they are completed. You could even make a way to switch between these two types of approaches for different projects, for more flexibility. Those are just some things that I can think of -- not too sure what direction you want to take your project. As was stated, such a system is quite an undertaking and maybe if you can find a way to write a new and unique method that handles one part of the process particularly well like the way branching is done, then you could either a) start on refining another piece and eventually have somethinig you could call a real piece of software, or you could b) leverage your understanding of one aspect of revision management to apply it to other open-source projects that are out there.

My #1 wish for improvements to current systems is speed. Although I'm currently forced to use a lesser known programed called RCS, I've also used ClearCase. Both are horribly slow. If there was one out there that 'just worked' and was fast, I'd want to use it. I don't care for an insane amount of features, pretty GUIs, etc. Just a simple system that was fast would be worthwhile.

I always look first for a plugin for VSNET, which is the reason that myself, and the company I work for, use SVN. In my opinion a system without plugins/tools is almost worthless to large scale development... just like having say a game engine with no tools / content pipeline.

Quote:

Original post by jregan My personal dream feature in a revision system would be a way to have it tell me all of the files tied to a particular incident/bug. That way when someone has resolved a bug, then I would be able to know right away all of the files that were modified, which version, and which "release" it was a part of.

Microsoft Team Server will be able to do that. You can set a requirement that a checkin is associated with a "work item". Querying for change sets related to a work item is then trivial.