On Tue, Dec 30, 2014 at 11:58:32AM +0000, smf wrote: >Converting from one format to another is not like a version control >system at all. True, and that is not what I suggested. We have 2 independent problems here. I was thinking of one of them, but mentioned the other one as an anecdote. Problem 1: Multiple slightly different revisions of the same code base (say, Commodore 64 KERNAL versions). Problem 2: Multiple different assembler formats. AFAIU, branches in version control are a perfect match for the first problem. For example, at work we have multiple branches of the code base, for each major version. Sometimes, bug fixes are ported between branches. When a release from a branch approaches, a release clone is made. Sometimes, bugs are found during the release cycle. Such bugs will be fixed in the release clone and then merged back to the relevant development branches. In this case, we have an additional rule that each branch must compile to a predefined output (the binary files). Other than that, it is not much different from how branches are normally used in version control systems. This blog post explains some best practices for using branches: http://nvie.com/posts/a-successful-git-branching-model/ I agree that for Problem 2, a workable solution could be to have translators for the desired output formats. It does not usually make sense to keep any generated code inside a version control repository. A special case of this solution is to agree on one format, and let anyone who disagrees worry about translations. >With multiple branches you have to do work manually, with a tool to >convert them you make one change and it's available in all of them. Your comment is valid for Problem 2 (multiple output formats), not for Problem 1 which is what I had in mind. When merging (say) changes to comments or constants between branches, there could be conflicts that have to be resolved manually. Some branch might not implement the functionality referred to by a comment or constant, for example. Marko Message was sent through the cbm-hackers mailing listReceived on 2014-12-30 13:00:05
Archive generated by hypermail 2.2.0.