Re: A programming wiki?


//\\\\o//\\\\annabee wrote:
På Wed, 27 Dec 2006 08:02:48 +0100, skrev Dragontamer <prtiglao@xxxxxxxxx>:

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

GRRR.. google groups... *mumble*

:) point in case? (technologywise)?

Yup.

My point is this: unless this programming wiki will do better than
say, CVS, I don't see any point in making it.

I do not know CVS. But, tell you this.
if cvs is more work, then :

1. enter url, press enter
2. click click click, project
3. click click - Function SetRect
4. rewrite this routine
5. press compile.

A typical run with CVS would be:

cvs checkout <-- may be in your IDE, could be from Emacs,
whatever.

edit the code
compile the code
test the code

cvs commit <--- again, may be part of the IDE. I expect
point and click or keyboard shortcut, but command-line exists
for those who want it.

That changes the version from 1.1 to 1.2, and any future user who
uses cvs ci on _their_ computer will be notified about an edit
conflict (if one exists) and then the version will change from 1.2 to
1.3.
etc. etc all teh way up to 1.9, then 1.10, then 1.11, etc. etc.

If say, 1.25 becomes very stable, and few people want to
risk "breaking" the code, you can use the cvs tag command
to create a new branch. So the smart people can start working
on ironing out old bugs on 1.25 while you start working on new
features in 1.25.1. Later, 1.30 may be merged with your 1.25.10
file, and cvs's automatic merging makes things slightly easier
to merge the two branches.

If it takes more then 10-20 seconds to produce the new exefile, under CVS,
then it is useless. (to me). I dont need no "versioning" control myself.
When I code, I allready know that the last version is fadding out. So
better delete it. If not, and I am just testing something, I just comment
away the code that is there. All of this takes no time. Writing code takes
usually no time, what takes time is to clearly understand the solution,
and then to write it is allmost an insignificant afterjob. Not allways
true, of course. Depends on the problem. For improvements and bugfixes,
its certainly true in many cases.

Ah yes, but if you are just "testing" something, but it takes a week
(say you are testing something really new), CVS would allow other
people to see what exactly you are testing, the changes made to
that code (using cvs diff, which in Emacs, is just point and click)

Thats what branching is all about.

what i mean is that, user1 creates project1, using version 1 of all
routines.
user 2, change routine xx, so it becomes version 1.1. Now user1 still uses
version 1 of everything, but user2 uses version 1 of everything and
version 1,1 of this spesific routine. User1 can upgrade to version 1,1 if
he wants to, by looking at the sourcetrees.

Yes, CVS keeps track of this. Heck, forget CVS, try RCS, the precursor
to CVS if thats all you want. (no web-interface on RCS IIRC however)

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)

State of the art, in programming tools, is what RosAsmers call laughing
"stock". :) not to be "uber" arrogant or anything. Its just one of the
strange facts of life.

Sure...

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.

No conflickts need to exists. Each user uses a uniqe set of
routines/files. If user2 is changing routine 103, and causes 102, and 133
to change as well, all those change without ever causing trouble for
user1, who uses all the prior versions/and data of those routines. By
inspecting the changes others made, user1 can upgrade his routines if he
wants to. Or both upgrade and modify at the same cycle.

?? On a wiki, anyone would be able to change the code. If anonymous
guy changes routine 103 while you are changing it, you've just created
a conflict.

Now, sure, if no one modifies those routines, then there won't
be any conflict, and CVS, as old as it is, is smart enough to figure
out when there aren't any 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)?

Forking? You mean merging in new changes? Maybe there could be some
temporary working versions, and then the creation of lasting new versions
is done by setting a checkmark at the end of the day or week. At that
time, all code that has changed, are stored in a new files, with a
diffrent version number. Maybe voting could be involved. The system must
take on to fully automate this. The user2 who changed the code, may or may
not add comments telling other what he did, but if he like them to notice
it, he may. Or the other users could just compile the new version, and see
for themself if they want the added stuff or not.

Forking is doing the "temporary" thing. Sometimes, things aren't
temporary
however :-p

For example : I make a program that scans some dir on your harddrive, and
passes each buffers to an encryption routine. It can do all the work, so
that the only thing you need to add is your own personal encryption
routine. All the userfriendly interface thingy, which take up most of the
work, and means less for the result, is done for you. You may have
expertise in encryptation, and you add in the missing important piece.
Will reduce your job to a few hours work, while another programmer who
knows how to make efficient userinterfaces, which are lots of work, but
not allways technically challenging, can work at that, without worrying
about those parts he hasnt any expertise/interesst in.

THOSE already exist however. They are called libraries and APIs.
In Java, they are called packages.

-- Branches. Closely related to the above problem. How do
you handle the forks (aka, branches) later?

Each change, form a new independant version. This is mostly just
textfiles, and it takes allmost no significant space. For 100000
modifications, this is a problem, but there could be ways to deal with
that.

Yes, CVS does that. Stores them as diffs actually, so they are very
very small textfiles. I think some modern system doesn't compress
them, because it is like, 1% faster in 1% of the cases :-p
</exaggeration>

Of course, the corresponding disadvantage is that...

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

Code is visible to all, so you read it. If it looks ok, and seems to
perform better, or add features that you want, you upgrade. If you dont
understand it, you dont risk loosing any data, as its all stored online
anyway. And theres no forced upgrade.
The server will keep track of all the routines that changed in the last
modification.

I should note that "Version Control" is that software that keeps track
of those changes. Look into it. CVS is old, and probably wouldnt
suit you very well. But I don't know of the modern easier tools that
people
use today.

[snip last comments]

--Dragontamer

.

Relevant Pages

  • Re: A programming wiki?
    ... that code (using cvs diff, which in Emacs, is just point and click) ... If user2 is changing routine 103, and causes 102, and 133 ... The point is not only to make the programmers job easy, but to make it easy for them to check out others work, and for users to check out the other programmers work. ... Basically it should be as simple as to mark in a list the projects he want to check out, and then download them all. ...
    (alt.lang.asm)
  • Security Advisory for CVS Slash
    ... There has been a security issue in CVS Slash code for the last ... CVS to upgrade now to the CVS tag R_2_5_0_41. ... Normally we do not make security announcements for CVS code, ...
    (Bugtraq)
  • Re: Promise Ultra100 TX2/FreeBSD-4.5/160-180GB HardDrives
    ... > Time to upgrade? ... >> or diff to the ata kernel code that will get these large drives ... > setup cvs access and do a cvs diff for the apropriate tags and files. ... an idea of necessary additions to the ata code to fix it. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Promise Ultra100 TX2/FreeBSD-4.5/160-180GB HardDrives
    ... > Time to upgrade? ... >> or diff to the ata kernel code that will get these large drives ... > setup cvs access and do a cvs diff for the apropriate tags and files. ... an idea of necessary additions to the ata code to fix it. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Finally - a decent 3 way diff/merge tool on Mac OS X (Araxis Merge)
    ... around 20% of my working life doing source code diffs/merges etc so it's ... (I tried git, but I ran into RPM-hell: git wanted this & that RPM, ... conflict with I already have, so I gave up after a couple of wasted hours.) ... I do a "cvs update" and take a copy of the working ...
    (uk.comp.sys.mac)