2009/7/6 Tim Edwards <[email protected]>: > > The whole idea of local and remote copies of components is effectively > a version control system. And if you've ever delved deeply into RCS, > CVS, git, and others, you'll know it's a non-trivial problem that > people have been attempting to improve for years. > > Xcircuit can be set up so that a master library takes precedence over > local copies in a file. However, it is not possible to track which > objects are local and which are external, or when something has been > overwritten with a newer version. To be a proper version control > system, one would want to timestamp every version of an object, and > have access to the entire history of every object. Should xcircuit > use git or some other version control system to track changes in a > project?
I think it is every chip-designers dream to have a working revision and configuration management system for their data. In all the projects that I have worked so far, the management wants a repository of "proven" modules that can be "just inserted" into new designs. The repository has mainly been a directory with a name and a date and a comment in a readme file somewhere which version to use and how to tweak things in case it is not working. Then a later feature add to that module forks another directory and in the end, nobody knows anything anymore, except management who says "but this worked last week..." git is probably great for linux kernel and gnome and other software projects, but I have found git more inconvenient for an FPGA project in VHDL than subversion. git is also pretty immature when it comes to being user-friendly to non-software programmers. And I don't think using hashes as revision numbers is better than having a repository wide increasing number as in subversion. I haven't tried other distributed revision control systems, but I would guess that they are better tools for SW-designers than for HW-designers. Besides, hardware in git tend to generate a lot of branches that become hard to maintain the way you want to maintain hardware: Merge all, except for these files that are unique to this project. What comes to my mind is that it would, of course, be nice to have a schematic toplevel where each block symbol has a version number and the combination of library and version number would check out that particular version of the schematics when navigating down the hierarchy or when creating the netlist. That would help getting rid of a lot of those dated-named directories. Then reproducing a particular product will be as easy as loading a configuration file that identifies which version (or hash) of each module file was used to create that product. I haven't found an open source configuration management tool so far and for my current project, that is something I am missing. Good revision/configuration management is not easy. I wouldn't tie any specific vcs into a software. git is notoriously changing the way they work and adding features as if every user is a capable command line hacker. cvs is too old and subversion is not used in most companies. Distributed vcs look nice at the beginning until all the code is supposed to be consolidated. In net based open source development, you don't get around it, in a company there is always one or two who denies using such "toys" and the timestamped named directories reappear. humble opinions, -- Svenn _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
