On Sat, May 10, 2008 at 10:29 PM, Justin Leung <jleung@xxxxxxxxxxx> wrote: > > Honestly, it sounds like SVN is actually a good fit here. Just because git > > is awesome for many things does not mean it is the end-all-be-all of > > version control systems. SVN still has its place as the last true > > centralized system. Given your constraints and workflow, why do you think > > git is better than SVN? > > The ability of inter-user (designer-verifier) code sync'ing without letting > the incomplete or incompatible RTL code to propagate to the main build > stream is going to facilitate the design flow and efficiency . > > The ability of local revision control means that no more over writing of > design files until commit . > > I think these 2 things will really buy us alot . Hi Justin, I was originally drawn to git for the exact reasons you identified in your 2nd email. Namely, it is extremely difficult in a p4-based environment to share intermediate work within a design team without pushing the work out to be visible by the entire team. "Inter-user design sync'ing" is exactly what I wanted. In its absence, we have made all references between files relative. This means you can flip over to someone else's netlist by changing one path (say to the top-level design file) to point into someone's private repository. That top-level file then includes everything else using paths relative to its own location, so you get the correct stuff automatically. Of course, you get tripped up all the time by stuff implicitly used and not named in the top-level file and its children... Now, it would be far better for this to be a lightweight branch in git, and then having people checkout this branch and use it. (Because, for example, while one person is pointing into another's tree, the latter can't change.) But p4 (and cvs) has trained everyone to think of branches as painful and for wizards only. Plus I am not personally interested in investing any time writing scripts on top of p4; the ideas I outlined in the previous paragraph were easier and almost as good as anything (easily) doable in p4 (but not as good as lightweight branching). I agree with other responses to your email that you may want to think about writing simple wrapper scripts that add tags to checkins with some simple incrementing numeric part to keep your back-end people happy. Yet other responses were distracted by the linearity of your centralized/shared checkins: the inter-design sync'ing you want, and the lightweight branching it may imply, aren't necessarily incompatible with the linear main public history that most design teams expect (and which is unavoidable in design work containing lots of unmergeable files, such as layout design). So I don't necessarily think you would be happy with Subversion (I'm certainly not happy with p4). There are two other issues you may want to keep in mind. In our chip design activities, we have a lot of very large files (100MB to ~3GB), and the p4 repository has grown beyond 3TB. Now, this is simply a data set size region which is not used by the git developers. I think the git data model is fine for large projects and files (Linus mused otherwise a few weeks ago, but it seems fine to me), but due to lack of use, various details when handling large files/projects remain to be worked out and/or optimized as much as the rest of git. It is true since I started watching there have been a lot of important improvements in this area. Secondly, you may also want to discuss with your IT people (or whoever is responsible for back-up) how git packs/repacks repositories. Ours were very uncomfortable with the idea that the _entire_ repository has to get re-arranged frequently. I think they would have been much happier with an approach more similar to how Unix systems were backed up in the 80s: have a level-0 repack which repacks everything, a level-1 which repacks only stuff added since the last level-0, level-2 since level-1, etc. To do this would be a pretty straightforward change to git-repack.sh, probably using .keep files. In each level it is clear what needs to be backed up. Anyway, good luck! Many of the things you touched on, or which I mentioned above, have been (partially) implemented or at least discussed before, so your requests aren't crazy. Unfortunately, in my case, having 6 surgeries in my family in the last year has kept me from doing that much useful for git along these lines and thus I remain stuck with p4 for now. -- Dana L. How danahow@xxxxxxxxx +1 650 804 5991 cell -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
