Hi Paul, Mondain schrieb:
Ok.. I dont see the problem here, what I mean is I'm not "splitting" the codebase. What I put on google is simply a library repository; all of the jars are self-contained and self-versioned, they need not be merged or updated. Whenever new versions of a particular library are released we will place them in the repos if they are not available via ibiblio. Do you feel better about this now?
Not really ;) We are actually splitting the codebase if we have two repositories that have their own versions. We can't merge the two later as r123 in the cvsdude repository is different from r123 at google code. When we switch completely to gcode, we would have to reinitialize the repository, sync everything from cvsdude and then re-add the JAR files that were in gcode before. For these JAR files, we would lose the history (which I know isn't too bad as there is no real history per file), but more important also lose the targets of tags that were created for Red5 releases. If somebody wants to get say Red5 0.6.3 anytime in the future, he must be able to check out a tag and get exactly the files that were used for this release. This won't work if we reference rXXXX in the gcode repository from the tag now and rXXXX will change to rYYYY when we merge with the cvsdude repository. Hope that made my concerns a bit clearer :) Joachim
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
