Re: C64 GS

From: Marko Mäkelä <msmakela_at_gmail.com>
Date: Tue, 30 Dec 2014 14:48:48 +0200
Message-ID: <20141230124848.GD1536@x60s>
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 list
Received on 2014-12-30 13:00:05

Archive generated by hypermail 2.2.0.