If a distributed model is used, this is how I would see local branches in use:
- Mirrors of the official repository - could be for speed reasons (one in europe, one in asia, or just in general to cover outages if the official repository is down). - For developers to make their changes easily available - instead of sending what could be a long diff to the mailing list, they could say 'these changes are in my repository at ...'. - For several developers who are collaborating on a big change - to have a repository that they can make their changes on, and when done, commit those back. I note that in all of these cases, this is basically functionality that CVS doesn't really support well. I'd have to double check, but I thought most of the distributed ones have a method to reparent - if you did a checkout from a mirror, made some changes and wanted to put back, you have to commit to the main repository so need to reparent to that. Second and third points could be done in branches in CVS, but then as discussed, the CVS branching/merging model isn't great. It's also unclear, if even in a branch, CVS should be used to store work in progress files, etc. I don't see the use of distributed repositories as a substitution of committing stuff back to the main repository. And while there could be reasons that repositories disappear, and thus so do their changes, that also isn't really different than right now. It probably isn't uncommon for developers to have changes in their local CVS repositories - if their hard drive crashed now, or they disappeared, those changes would be lost. The only real difference right now is that no one would know about it. If anything, those extra repositories actually help out in this case. If someone has some changes and say 'you can get it at ABC', and it looks interesting and I do pull it down, now I have a local copy myself, so if ABC goes away, it still exists. I'll note that in no way do I see it being a requirement that developers make their changes available in this way - you could still send out diffs to the mailing list, etc, and decide not to look at other repositories. I don't really see that providing more options is a bad thing. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire

