Jamin W. Collins wrote: > I prefer an alternate structure where you start with the project as a > top level. This keeps all project (package) related files under one > directory in the project: > > project/ > trunk/ > branches/ > tags/ > vendor/ The only problem with this is that if you maintain N packages, and you presumably set up svn:externals pulling in all N, so you can update your whole source tree with one svn up, then subversion will currently open n connections to your server. Due to some bugs it will keep all N connections open until it's done with the whole update. If you use subversion over ssh, this is pretty bad. I have successfully fork bombed my server with subversion. (N was 40 or so.) Not to mention all the other limitations of svn:externals. It's fine if you're only maintaining a few packages I guess. > Either way, I suggest the addition of a vendor/ directory to track > differences in upstream versions. The reason for this will be clear > (see below). Vendor is just a branch so I don't understand why it should be kept separate. I use branches/package/upstream for this, and put vendor tags in tags/package/upstream_revision_x.y. I am considering changing the latter, which is derived from what cvs2svn does to old cvs-buildpackage managed repositories, to something like tags/package/upstream/x.y -- see shy jo
Attachment:
pgp1G55EwFypC.pgp
Description: PGP signature