New tree or just a branch when changing languages?

[Database Administrator]

Assume a project was written in one language, you want to make a
transition to a new language while still maintaining the original
code. Put another way, it's a typical versioning issue but with the
added complexity of changing languages or versions of languages.
You've released version 1.0 and are now maintaining a maintenance
branch of version 1 and a development branch for version 2. But
version 1 was written in perl 5.8 and you want to do version 2 with
perl 5.10, or version 1 was in .NET 2 and version 2 will be in .NET
3.5 or what have you. Can you have a common trunk in these cases or
are you forced to have two separate trees?

I'm running up against this problem for the first time and am looking
for thoughts from people who have experienced this. Thanks much!

Mike Lerch
http://mike.lerchgonzalez.com

[Database Administrator]

Hi,

I'd go for branching if your tool supports it correctly, and if you're
switching language versions.

If the language is totally different... them I'd go for a different
tree, because there's no way you can use the merging facilities...

pablo

On Jul 31, 4:47*pm, Lerch wrote:
> Assume a project was written in one language, you want to make a
> transition to a new language while still maintaining the original
> code. *Put another way, it's a typical versioning issue but with the
> added complexity of changing languages or versions of languages.
> You've released version 1.0 and are now maintaining a maintenance
> branch of version 1 and a development branch for version 2. *But
> version 1 was written in perl 5.8 and you want to do version 2 with
> perl 5.10, or version 1 was in .NET 2 and version 2 will be in .NET
> 3.5 or what have you. *Can you have a common trunk in these cases or
> are you forced to have two separate trees?
>
> I'm running up against this problem for the first time and am looking
> for thoughts from people who have experienced this. *Thanks much!
>
> Mike Lerchhttp://mike.lerchgonzalez.com

[Database Administrator]

On Aug 9, 10:17 am, pablo wrote:

> I'd go for branching if your tool supports it correctly, and if you're
> switching language versions.

I'd go for branching too.

However, my reasons would not relate with
merging or the internals of the representation,
but with the identification of the configuration
item from the point of view of its use, i.e. its
relations with other items in the software
configurations it is involved into.

Mostly thus with the possible records of
auditing its use, and the resulting
dependency trees.

I.e. for /essential/ instead of /accidental/
reasons (in Aristolelian tems).

Marc

[Database Administrator]

On Aug 10, 7:07 pm, Marc Girod wrote:

> I'd go for branching too.

Er... and if your tools don't support branching,
just versioning in the same branch...
if your tools support it properly.

Marc

[Database Administrator]

On Sat, 9 Aug 2008 02:17:24 -0700 (PDT), pablo wrote:

(fixed top posting)

> On Jul 31, 4:47*pm, Lerch wrote:
>> Assume a project was written in one language, you want to make a
>> transition to a new language while still maintaining the original
>> code. *Put another way, it's a typical versioning issue but with the
>> added complexity of changing languages or versions of languages.
>> You've released version 1.0 and are now maintaining a maintenance
>> branch of version 1 and a development branch for version 2. *But
>> version 1 was written in perl 5.8 and you want to do version 2 with
>> perl 5.10, or version 1 was in .NET 2 and version 2 will be in .NET
>> 3.5 or what have you. *Can you have a common trunk in these cases or
>> are you forced to have two separate trees?

> I'd go for branching if your tool supports it correctly, and if you're
> switching language versions.
>
> If the language is totally different... them I'd go for a different
> tree, because there's no way you can use the merging facilities...

Branches are still useful even if merges do not work.

Let's say that I branched from mainline-1.5 (written in, say, Python)
and started converting everything to Perl, and two weeks later came up
with Perl-1.2. If there is, by then, a version mainline-1.6, then
there may have been bug fixes which I should rebase into my Perl
branch. I must at least prove that I have looked at them, before
merging and calling my Perl code mainline-2.0.

(And besides, you probably have documentation and stuff which is
language-independent and which can and should be merged.)

/Jorgen

--
// Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!