Hi everyone,
this is not really a question, but more some food for thoughts on how to optimize an fpga development flow leveraging the benefit of a vcs.
I've been using svn since sometime now and I cannot imagine a world without a vcs under your belt when dealing with complex systems in a collaborative environment.
In the past I've always followed two simple rules: 1. never break the trunk 2. commit often
The reasons behind these two rules are quite simple and I stick to them because from them it derives a set of additional rules which allow you to respect the one above.
The first rule is there because without it anyone new in the team cannot simply checkout a copy and rely on it. This implies that commits to the trunk are performed when a feature or a bugfix is completed and does not break compatibility with the rest of the system.
Allowing a newcomer to easily get into the flow alleviates hours of training, but even experienced designers do need to rely on a stable version to perform their regression testing and/or add features to it.
The second rule is needed because the very purpose of a vcs is to track changes as regularly as possible so that you (or somebody else) can roll back and forth and use what is most appropriate at any given time.
Apparently the two rules are in contraddiction since the first advocates few commits (only the good ones) and the second lots of commits (even broken ones). To benefit from both of the two worlds 'branching' come to rescue. When branching the trunk we set up our working environment in a clean way and we can mess up with it as long as we want, until the feature/bugfix is complete. Only at that point we can merge it back into the trunk so that the trunk gets all the goodies we worked on.
Working on a branch leaves (no pun intended) the trunk safe from exploration efforts and allows everyone to rely upon it. After all, an healthy trunk means an healthy tree.
The pitfall here is that too often people branch and then never sync with the evolving trunk, so when it is time to merge it is a hell! Syncing regularly with the trunk allows to keep the branch on track without the risk to fight when it is time to close the branch and move on.
I have deliberately left out of the flow the concept of tagging because that is not adding too much to this conversation and might be treated separately (maybe another thread ;-)).
If you find this flow somehow lacking important features and/or missing completely essential points which are relevant to fpga development flow I'd appreciate if you could share your thoughts.
Al