LKRaider wrote:Hmm, I find this interesting. Ignore this whole brainstorm if you want
::
You make an upload page that requires login.
People would register for an account (by email? by a form on the site?) and then be able to login and upload a diff to the server.
The diff file would be named as: timestamp + patchname + md5 + userID
Server side, it will look into the upload folder, which would be like a queue (ordered by the timestamp).
Server will try to patch the trunk with the diff in the queue.
It will generate a log of the process with name: patchname + md5 + UserID
-> If md5 was already tried on current trunk, it will return the last log contents. (check md5 on success and errors folders, or keep track on a separate file). <- this is optional. Will just make server not waste effort
-> If error occurs, it saves the log on error folder.
-> If success, saves the log on success folder.
When user logins, the script parses the folders for the userID on the filenames and counts the errors and successes, then prints it on the page, with links to download the logs.
Alternatively, a database would be better suited maybe (more stats), but need more implementation work probably.
The only bad thing on you thoughts is that i had them 3 weeks ago
The system allows that all.
Some info about the working:
- It fetches the patch from a directory on which the webserver has write access
- It updates it's trunk working copy
- It tries to merge ever patch into the updated working copy, (no changes at the code) (merge error file is created here)
- If the previous merge was successful it will merged with code changes
- It will compile the patched working copy
- It copies all needed files from the compile directory into a seperate directory and zips them
- The zipped file is putted back into a directory where the webserver has access
- It continues with the next patch file
- When finshed with all patches it tries to merge all patches together. If one fails in the first test it will be skipped.
- It get's compiled
- It will be putted into the same folder like the single patch zip files
So far to the compile system. That system uses the compile farm scripts available on svn. The patches get compiled alphabetical ascending. But the idea with the timestamp is not bad. The problem is using strings in shell. And the problem is to find some short words about the patch.
Curently the files need to be saved like: found_bank_r4742.diff
first the name with underscores. Then the svn version on which the were created. This is not needed yet for the system itself. It is only part of the zipped filename later but can be removed. The only thing that is necessary is the .diff as file extension. .patch is not implemented yet, but that rename can the webserver change while uploading the patch files.
Website register will be with nick, e-mail and password. It is using a Database too. But it's kept small with only informations about the patch, user login data, and download stats. Rating of patches need to implemented too. As said, a compiled version of only patches with a rating better then let's say 7 get compiled, is possible with that. Or patches which aren't finsihed but uploaded to get bug tested or anything else.
I recognized now that the last compile failed on my waypoint stats patch
So i have to correct the one error
The last week there were no errors.
. Maybe he's too busy with his patches 
