On Tuesday 04 September 2007 10:08, Klaas Freitag wrote:
On Monday 03 September 2007 18:20, Cornelius Schumacher wrote:
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?
Merge requests are certainly useful. I just wanted to say that the hard problem of branching is not creating the branch, but merging it back and we should put enough effort into the merging part to make this a good experience for the user.
- 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.
But normal projects don't use directory notation. They use the colon notation.
- 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.
Sounds reasonable.
--
Cornelius Schumacher