Anders Molin - Professional Profile

Good ideas Paul, thanks Smile | :)

- 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 Wink | ;)

Michael.

You have some good ideas, thanks Smile | :)

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

I agree, there is going to be a standard install package as in a commercial project Smile | :)

I also agree in the comments about the UI, it's important to make a good looking program, because it's what the users see, and of they judge software by the UI Wink | ;)

- Anders

Money talks, but all mine ever says is "Goodbye!"

Without wanting to start a flamewar here I'd like to make a few suggestion to think about before starting a whole new SCM system:

- There are many opensource SCM's out there. Most of them are "work in progress", i.e. they are improved and worked on constantly. And some of them are even good!
- Writing an own SCM system would mean "reinventing the wheel"
- SCM systems are not easy to code. Many things which seem easy at first turn out to be very complicated (like e.g. merging/branching).

So I would suggest the following:
1. Pick one of the opensource SCM's (one which is still worked on and not "dead" yet)
2. Help the developers there to improve this SCM on windows, i.e. create an easy to handle installer, implement windows-specific authentication, port the server part into a service, add config dialogs, ...
3. Add the defect tracking system to work with that SCM.

This would not only reduce the work, but also the risk of failing (as I already mentioned: SCM's are not trivial!).
And IMHO it is better to help improve an existing SCM and make that perfect than start a new one and most likely end up with two SCM's that "work" but are not perfect.

Currently I'm using Visual SourceSafe, and what really takes too long Sleepy | :zzz:

in a big project worked on by multiple users, are, for example the following tasks:
* displaying a chronological list of changes to all files between certain dates, starting from a given subtree (project) and acting recursively
* displaying a list of files checked out by myself or someone else, starting from a subtree (project) and acting recursively

When performing these tasks under VSS in a subtree with a large number of files (couple of thousand), this can sometimes take quite a while (minutes). This can be avoided if this info is appropriately sorted (for example when put in relational database tables with indexes).

I'll throw my two cents into this discussion as well.

I think that a balance needs to be found between a feature rich system and a simple-to-use system. Below I've listed some of the capabilities (requirements) that I think such a system should minimally have (above and beyond the basic get, check-in, check-out, etc):

1] Storage Efficiency: Most SCC systems store revisions using a delta model, where only the changes are stored. Without this capability, three revisions of a 500Kb source file with two one-line changes occupy 1.5Mb instead of ~502Kb. This becomes more difficult for binary files, but is still important, as binaries are usually even bigger than text.

2] Labeling: Code is never developed in isolation from other code. Without the ability to track logical changes together, there is no way to track or understand what belongs together and what doesn't.

3] Branching: This is an essential capability for any SCC system. Whether it's to support concurrent changes to a single source file, or create multiple versions for different clients - the ability to manage multiple evolution paths of a single item is critical.

4] Batch Interface: In most real-world, multi-user environments, there is a need to automate builds, comparisons, and other SCC operations. A batch interface allows users to easily implement automation jobs that can support their specific needs. A commendable feature would be to provide an ANT task for our SCC.

5] Criteria-Based Search: I can't begin to mention how many times PVCS has made me want to scream because there is no search capability! This is a must have for any practical system, and should allow searches on both metadata and content.
-----------------------------------------
The features listed below are not necessarily first version items, but their incorporation would make this tool a cut above the rest:

6] Physical vs. Logical Views: Although source code usually has a predetermined physical organization on disk when extracted, that is not always the most convenient way to browse or search it in SCC tool. Allowing physical organization to be separately defined from the logical structure can be a big plus.

7] Extensible Metadata: Since the server-side component is assumed to be a relational-database, it creates a perfect opportunity to provide for extensible meta-data for SCC items. In fact, this could be the basis for tying defects to source code. It would also allow immense power for searches and reporting -- imagine being able search for all code used by a particular project or department.

8] Partitioning: If you have many groups sharing a single SCC database, you really want a way to partition the contents so that only certain items are accessible to the appropriate individuals. Extensible metadata may make this substantially easier (see above).

9] Phased Concurrency: In many real-world systems, developers are actually working on more than one release of a system or software component at a time. To support this capability, an organizational structure needs to exist that allows a project team to partition the code by release or lifecycle stage. PVCS handles this with a concept called promotion groups, however, extensible metadata may provide a more powerful and flexible implementation.

10] Dynamic Links: Sometimes it is very desirable to link source code between to different projects (shared headers, shared classes, etc). To support this, most SCC systems provide the concept of shared/pinned revisions. However, this really isn't enough. Sometimes you want shared code to progress dynamically without having to manually share individual items. To really provide this ability, you have to be able to link entire folders (or metadata sets) so that a change in one place is always reflected in another.

“The State exists for the sake of society, not society for the sake of the State.” -- Woodrow Wilson (28th U.S. President)

Reply to this thread with your ideas

- Anders

Money talks, but all mine ever says is "Goodbye!"

Hi Anders.

First Off, congratulations and condolences for taking on such a possible quagmire of a project.

I’ll put some ideas out there just to get the creative juices flowing.

Source level integration to track bug fixes and commits to the repository. I think we can use attributes, reflection or, simple flags.

Integrated e-mail capability.

Some "eye candy" on the client side. (Pie, Bar, and other charts).

A web service.

A rss feed?

Again, these are just things I am throwing out there. Feel free to ridicule any of the ideas or insult me personaly.

-Chris

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:
First Off, congratulations and condolences for taking on such a possible quagmire of a project.

Mmmm, thanks, I guess Wink | ;)

You have some nice ideas, great Smile | :)

- Anders

Money talks, but all mine ever says is "Goodbye!"

1. A good name. BugZilla is taken unfortuanatley Big Grin | :-D

2. A client/manager viewable interface. We are geeks, they are not. They do lots of testing and they are not going to use this system if it looks horrid and is complex to use. I have only just managed to get my sales guys into using a standard bug sheet (Excel.) It started out with all sorts of nice features, but has ended up being a very simple list and that is what they like and can use. They are not stupid, they just don't understand things like the difference between an error message and a description of what they were doing. Simple Mode.

3. How about using the Task List in VS.NET to list the bugs assigned to Developer X? When he ticks something as done it updates the Defect Tracker system. The project lead or manager will assign the bugs and all the developer needs to see are his bugs inside his IDE.

4. Feedback/disccussion/comments on a defect. This is a must IMO. Often someone will report a bug but the description of the problem makes no sense to us developers. We need to be able to click on that defect and write back "What the hell are you talking about?" and then they can write back "Sorry I was drunk when I wrote that bug, what I meant was X Y and Z." So each defect needs a way to be discussed. Only once the developer understands the bug should it then become a fixable/active item. Up to that point it needs to be marked as "Undergoing clarification." I get frustrated with clients when they moan at me for not having fixed bug X when in fact they have not gotten back to me on that bug because I asked them a question about it. Clarifaction.

5. Attach screenshots to bugs, a must.

6. Import facilities. From CSV or Excel. Not all clients will be happy or able to use a web-based defect input screen. So we provide them with a standard Excel spreadsheet which they can input in. Then they email that back and we import it into defect tracker.

7. Quick inputting of many similar bugs. This is where Excel is nice, you can type in a bug and then copy and paste it five times and then go back and change just the small details that are different from bug to bug. e.g. there may be a display bug which affects the Home page, Login page, Client page and Orders page. The bug sheet reflects each bug individually to ensure it is squashed across all those different areas. Now with most defect systems you have to type in the details of a bug, click Save, then click Add, then type in the details again and click Save then click Add etc. But we need an easier way to input than that. Either have a "Copy Bug" button or have a spreadsheet view method of inputting bugs.

8. Really like the idea of linking defects to code versions, very cool idea. We need to make this easy for defect inputters though. My boss and my clients are not going to understand "Select app version." They just want to bang in a defect and leave it up to us to fix. We obviously need to see which version a defect pertains to.

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

I like your ideas, what else is there to say?

Paul Watson wrote:
3. How about using the Task List in VS.NET to list the bugs assigned to Developer X? When he ticks something as done it updates the Defect Tracker system. The project lead or manager will assign the bugs and all the developer needs to see are his bugs inside his IDE.

That one is very Cool | :cool:

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

"Defect Tracker" may not be the right name, since it could be used to track user suggestions, enhancement requests, marketing wish lists, "future release" features, as well as bugs. The more people who buy into this kind of tool in an organization, the more likely it will succeed.

Best wishes,
Hans

Good ideas, if the UI is a bit flexible it's easy to use it for all those thing.
I chose the name, because it's the most used name for such systems, of course we need a new name before it's finished Smile | :)

- Anders

Money talks, but all mine ever says is "Goodbye!"

Anders Molin - Professional Profile

Summary

Groups

Reputation

Privileges