Do a "cvs tag" in apache before removal and after removal, I think.
You probably already know to check the perms and ownership after you cp, since repositories are so sensitive to that. Might want to save an "ls -lR" of the original apache apr dir somewhere for reference, before you do anything. :-) Also: > 2) On remote machine > cd apache-2.0/src/lib/ > cvs rm -R apr > cvs commit apr > > cd > cvs co apr > cp -R apr apache-2.0/src/lib > cvs import apr So we'd maintain two separate repositories for APR, one in Apache's repos, one in APR's own dedicated repos, and keep them in sync manually? You probably want to do a vendor branch in that case. Another solution is what Subversion does: developers simply check out APR into a subdir of the Subversion project. This means they are always working with an APR that's directly from the APR master repository, which is usually what you want. For distributions, you package them together of course, and maybe use a date or tag in APR to make sure that Apache doesn't continue to follow new APR development even while Apache is frozen for release. If you're going to expect people to remove and recheckout their APR subdir every week or so anyway, then this way is probably best. If you don't want to track APR dev so closely, then a vendor branch is probably best. -K > The final part to this, is that we would need to do a fresh cvs import as > a cron job on locus every once in a while. I would suggest starting with > once a week, and moving it up as necessary. > > I would expect any developer working on both APR and Apache to do: > > cvs co apache-2.0 > cd apache-2.0/src/lib > rm -Rf apr > cvs co apr > > I'm not 100% sure this will work, but it sounds and looks like it will to > me.
