On Monday 03 September 2007 18:20, Cornelius Schumacher wrote: Hi,
The general concept looks fine to me. As a side note: I would focus on the merging aspect, not on the branching aspect. If merging is too hard, branching doesn't make much sense. True, however even if merging has to be done by hand, merge requests still are usefull - or did I get something wrong here?
- Wouldn't it be more consistent to use the namespace notation for the branches, so call a branch "home:<person>:branches:branchProjectName" instead of "home:<person>/_branchprojects/branchProjectName"? Hmm, no. Since branch projects are still real projects, I think they should use the normal directory notation.
- How is the tracked from which project the branch originates? For simplicity, from the project- and package name. However I realise that I have to remove the optional names from the branch API call ;-)
- Why not call the branch notifier "merge request"? That sounds more like what is meant to be to me. Yes, changed that.
- What is the meaning of the "name" and "desc" elements in the merge request? Name: "Make it all cool patch" Desc: "This patch adds the ability to fly to the project" I thought it might be usefull to find out what the patch is about also without reading the patch ;-) And basic rule: Everything needs a name.
- Maybe it would be better to store the merge requests in an own hierarchy instead of the source tree, so use "GET/ PUT /branch/<project>/<package>/_branchrequest" instead of "/source/_branches". The requests aren't really source data, so it would be a bit confusing to have them in the source tree. Correct, but I think we should have a toplevel dir /requests because there probably will be more like rename, drop, etc requests.
- For listing the branch requests of a user it would probably be better to use a parameter instead of a pseudo path element, so something like "GET /branch/?user=<username>" instead of "GET /source/home:<person>/_branchprojects". Yes, changed.
It's clearer, if the PUT is only used for writing a resource without side effects. Also accepted.
Thanks for the feedback, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org