| ID: | 4705 |
| From: | rn...@igor2.repo.hu |
| Date: | Thu, 28 Jan 2021 04:49:31 +0100 (CET) |
| Subject: | Re: checking out edakrill (Re: [pcb-rnd] trunk does not compile |
| in-reply-to: | 4703 from ka...@aspodata.se |
| replies: | 4707 from ka...@aspodata.se |
Hello Karl, On Wed, 27 Jan 2021, karl@aspodata.se wrote: >Igor2: >... >> 2. do an svn checkout of edakrill and configure it as a local library path >> >> svn://svn.repo.hu/edakrill/trunk/user >... > > Doing >$ svn co svn://svn.repo.hu/edakrill/trunk/user >$ mv user edakrill You can do that in one command: svn co svn://svn.repo.hu/edakrill/trunk/user edakrill >$ find edakrill -type f -name 0603.sym >edakrill/trunk/user/gedasymbols.org/dj_delorie/symbols/tbd/0603.sym >edakrill/user/gedasymbols.org/dj_delorie/symbols/tbd/0603.sym >$ find edakrill -type f -name 01005.krill >edakrill/trunk/user/gedasymbols.org/dj_delorie/footprints/nv2pad/01005.krill >edakrill/user/gedasymbols.org/dj_delorie/footprints/nv2pad/01005.krill > > I get duplicates of every thing... > > Doing (using the mirror instead of svn.repo.hu) either of below > solves that. This doesn't depend on mirror or not: the repository itself doesn't contain tose diplicated, dj_delorie has a directory only under trunk/usr/gedasymbols.org and he does not have one directly under user. The most probble thing is that you mixed two checkouts using mv on your local file system. Whenever in doubt, you cna use server side ls: svn ls svn://svn.repo.hu/edakrill/trunk/user Mirroring works on svn database level, not on file or checkout basis. It can only do 1:1 copies of the repository, it can't create or move files or merge different repositories. So it's very unlikely you will see different files on different mirrors using the same revision numbers. If you do, that's a real big problem. > A) >$ svn co svn://aspodata.se/edakrill >$ svn co svn://aspodata.se/edakrill >edakrill/trunk/user/gedasymbols.org/dj_delorie/footprints/nv2pad/01005.krill > > B) this is where you need to check if you are in an empty directory >$ svn co svn://aspodata.se/edakrill/trunk >$ mv trunk/ edakrill >$ find edakrill -type f -name 01005.krill >edakrill/user/gedasymbols.org/dj_delorie/footprints/nv2pad/01005.krill > > So that is something I don't understand about svn, why the "trunk" > thing... It's just a convention. What I really love about svn is simplicity: on protocol or C code level it doesn't know anything about branching, tagging, production vs. development, permanent vs. temporary playground things. All it does is having directories and files in a tree, then it's up to the user to work out conventions about what directories the project should have and what those directories mean. I find this the true UNIX approach: provides a few generic basic operations extended with versioning and lets you combine them in whatever way you want, instead of trying to provide hardwired complex solutions for specific custom workflows like tagging or branching. There are a few such convention recommended by the svn book and a few that are not in there but got widely adopted: - /trunk is where main development takes place - /tags/version is a 1:1 copy of /trunk (that in an ideal world never changes after the copy): a snapshot of trunk at the moment of a release - /work is where we do things that support development but are not part of the release tarball; since it's not in /trunk, it doesn't get copied to /tags. That's why we have bug_files or OS packaging there - /vendor is a bit similar to work, we first import external stuff there, but unlike in work, we don't do modifications in /vendor, they are the "easy to figure and reproduce what exactly got imported from an external non-svn source". For example if you look around at r2, you will see the whole project started by importing a snapshot of pcb-20110918 into vendor/ that I than svn copied into trunk/. Since the unchanged versions are committed first, all changes ever made can be traced back. (This alone wouldn't need /vendor; that dir is just for convenience, when it's not so trivial as with r2, it's usually easier to figure what the original import of an external project was by name looking in /vendor). - /branches/brnachname is like /tags, normally the copy of /trunk at the point of branching, but unlike tags, with a lot of local modifications afterward. We don't have too many of these because I prefer planning out development ahead and coordinating the effort which on any "small" (less than 50 active developers) project should normally allow a simple linear development process. Plus we have a local edakrill convention: at some point I imported the whole database of gedasymbols.org. (I decided this will be a one time import and I won't do re-imports from time to time, and that we won't change these files, so I didn't follow the /vendor way of doing it.) However, I expected some users who did contribute there to contribute here as well, and I know how users will have duplicate file names, I decided that: - each user has his own directory under trunk/user/ so there's no file name collision with other users - for simplicity I just pretend the whole gedasymbols.org thing is one user, who never changes content; this assumes gedasymbols.org already solved the issue of duplicate filenames within its database, and as it's a separate user on our side, it won't collide with anyone else - users who have write access to both can upload to both, without collsision, even if I change my mind and import again from gedasymbols. So the only legit duplicate you could see is duplicate users, like user/erichvk and usr/gedaymbols.org/erich_heinzle. We have /trunk/user/ instead of having our users directly in /trunk because /trunk also hosts the whole web engine, with cgi scripts and htmls and pngs and I didn't want those to mix with the data. HTH, Igor2
Reply subtree:
4705 Re: checking out edakrill (Re: [pcb-rnd] trunk does not compile from rn...@igor2.repo.hu
4707 Re: checking out edakrill (Re: [pcb-rnd] trunk does not compile clean?) from ka...@aspodata.se
4709 Re: checking out edakrill (Re: [pcb-rnd] trunk does not compile from rn...@igor2.repo.hu