Re: A programming wiki?

//\\\\o//\\\\annabee wrote:

GRRR.. google groups... *mumble*

[snip]
I am much of the view, that the current browser technologies are way to
poor to make this a really worthwhile effort. Even on the latest iron,
using a broadband connection, posting to a PHP forum, is slow as a dog,
and at least much too annoying for developing software. But I also cannot
see any reason why it couldnt be made to work in some way. Since we are
not all programmers, maybe it could even make sense to create spesific
browser variant to assume this kind of thing.

The problem I see is not _creating_ such software, but creating
software
that beats CVS/SVN/Monotone/GNU Arch/whatever on a remote server
+ the devtools already avaliable for it.

Take CVS for example. Supposedly, it is very primitive compared to
other version control software, but it allows 2 different people to
edit
the same file simultaniously without too much problems.
Checkouts/Checkins aren't that big a deal, and it is still possible to
fork a project and merge it back in (I'll bet with some effort). I'm
not
too keen on CVS myself, but at least I saw in a book that it
can be done :-p

Throw in Emacs, where you can do whatever key-press you want
to do a checkin (Pcl-cvs is only C-c C-c to do that), and a somewhat
easy update (M-x cvs-update), I don't really see a reason to go
to a "wiki".

My point is this: unless this programming wiki will do better than
say, CVS, I don't see any point in making it. Already, there are tons
of tools avaliable that are standard in any modern developer team.
Add in some $$ from a company, and you can have standard
state-of-the-art technology (whatever that is for Version Control...
probably not CVS :-p)

Anyway, some issues that need to be resolved are:
-- Edit conflicts. How to "merge" code together when 2 people
work on the same file? The one on Wikipedia is not nearly robust
enough to resolve Edit Conflicts.
-- Forking. How is it done? How easily will it happen? How will
you organize it so you can fork experimental code out and
merge it back in later (after testing)?
-- Branches. Closely related to the above problem. How do
you handle the forks (aka, branches) later?

Also of course, avoiding the sure problem of 20 people compiling
all the same code on the same server instead of on their home
computers... mentioned in a different message.

------------

To be fair however; there would be some advantages...

* A contributor can read code, change it, and leave.
Totally anonymously

Of course, the corresponding disadvantage is that...

* A malicious user can read code, change it, and leave.
totally anonymously.

So there is some give-and-take here. Also, the fact
that a contributor needs to read/learn a LOT before he can
really contribute well removes a key advantage of a wiki.
Contributions from the "common man".

--Dragontamer

.