I've added comments inline, let's hope formatting remains.
Have a look at the CoherentTrees project of mine after reading the inline text. inline On Sat, Apr 17, 2010 at 12:15 PM, Henrik Feldt <[email protected]> wrote: About the status of tagging and versioning. Tag 1.2.0 of core, which is my main dependency isn't building. Try checking it out and doing nant in the root, yourself. Yes, that's because IIRC 1.2.0 was released on SVN and it was using svn:external to the buildscripts at that time. Even if the current 1.2.0 git tag had the buildscripts it would probably fail because the build scripts had some references to svn to set the assembly or file version. However, it does compile, and you don't even need to build it, you can just get the DLL from somewhere else and copy into the project's lib, just like every other project does. . Let git tags correspond to released versions. Never backtrack on these or release "another" tag as the same version. Did this ever happen (this backtracking)? :-/ No, I meant according to the tags in git, like you explained above. Right now I'm working on the coherent tree. Afaik DynProx was merged with C.Core, so perhaps another build of all projects against a newly tagged 1.4 version would be in order? What happened to 1.3 ? "Internal version" with .IO namespace at the moment, still waiting for pull request to come true. The coherent tree is built with git submodules which go against specific hashes of the respective code trees. In this way, if all projects are tagged appropriately and this is reflected by the tags of the submodules it would be easier to track dependencies. . Let's move away from binary dependencies. Code is code, so if we specify that C.Components.DictionaryAdapter depends on C.C.Binder 2.3 and C.Core 1.4, this should be true for the code tagged in that way; so C.C.DA could have a structure /lib/C.C.Binder, /lib/C.Core where both of these folders are submodules against the tagged versions. Submodules vs binaries has been already discussed, and binaries won. It's simpler and faster to build. With submodules you end up with multiple copies of nested submoduled projects (e.g. Core) (I asked about this: http://stackoverflow.com/questions/1419498/git-nested-submodules-and-depende ncies , didn't get any satisfactory answer) and each submodule with its full (mostly duplicated) history unless you do a shallow submodule, which isn't standard ( http://stackoverflow.com/questions/2144406/git-shallow-submodules ). This raises the barrier for contributors. If my plans come true, I'm going to integrate this with horn. Hence, a submodule with a tag/hash could simply be tracked by horn and robocopied, or a symlink could be created through p/invoke. In the end, it's equally slow, if not slower, to check them all out when they have binaries as dependencies. If the contents of the submodule is simply copied by horn to the "new" location in the /lib/ folder of the project to build, there is no problems with speed. Finally and nonetheless, horn is slow as well and it's easily scripted/programmed, to have all dependencies fulfilled automatically. See my contributions to "Dependency problems" for more of my thinking on how this could work. Besides, I believe many programmers using Castle don't just use the binaries, but adopt them a little bit as well. >From this we can say, if the tagged submodules for C.C.DA is not the same as those specified in one of the coherent trees, it's an error from the part of the developer of C.C.DA, and should be fixed. If I understand correctly, this would be something like going back to the old SVN monolithic trunk build (except with submodules)? I tried building that back when we started the git migration and I finally dropped it for the reasons I mentioned above. I think horn is a better solution for this problem. See the above. No, it would not be more monolithic than it is with binaries at the moment and with all the other open source projects. Think about it, what easier to fix? Binary mismatches with perhaps public APIs gone missing, AssemblyFileVersions forgotten to be incremented, or is it to make the source code compile with a package management system like horn? The problem as I see it with horn right now is that it's using binary dependencies just like castle is, and I'm trying to attack the problem at the root (with source) rather than at the top (with assembly redirects etc). Furthermore, it would be different in another way from SVN. Then, the problem was that the trunk needed to be in a coherent state all by itself, and it was also developed upon. A dependency was not tracked through a hash tag, but through the fact that it was on the same branch (i.e. trunk) as everything else. This made it an impossible coordination effort to release. A checkout of a project would then just be to do a $ git pull git://github.com/haf/Castle.Core.git haf-Castle.Core and then $ git checkout 1.3.0 $ git clean -f -d $ git submodule update --recursive I don't follow here. What submodules would Core have? None, bad example, sorry, say C.F.AutoTx then. Also -recursive doesn't seem to work, but git submodule foreach "git submodule init ; git submodule update" seems to do the trick, fairly well at least. In the end, and again, scripting it is easier. Cheers, Mauricio Cheers, Henrik -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
