Re: Version issues
Sankar Virdhagriswaran (sv@crystaliz.com)
Mon, 10 May 1999 18:38:00 -0400
Message-ID: <017801be9b36$681505a0$e6ea7392@honeybee>
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
To: <dbarrell@opentext.com>
Cc: "Versioning" <ietf-dav-versioning@w3.org>
Date: Mon, 10 May 1999 18:38:00 -0400
Subject: Re: Version issues
>
> I see the problem - I haven't seen any proposed solution to it in the
> current spec. Should this be client or server side functionality and
should
> it even be exposed in the protocol? I would argue that it doesn't matter
> where you put it and it should therefore not be explicity included in the
> protocol.
>
The solution to this problem is achieved by using activities and
configurations appropriately.
> identifies a conflict. We simply have to put a protocol and structures in
> place which allow the server and client to communicate about these types
of
> issues.
>
As I say above, activities and configurations help address the problem
during merge time.
> Simple versioning in my mind also excludes multiple trees and parallel
> development.
>
I do not believe SCCS supports branching. So, you and I are agreeing.
> In my mind simple configurations do not include parallel development.
>
I guess this is part of the debate. I think configuration management is
essential for parallel development and I don't see much of a benefit for
having configuration management without support for parallel development.
But, that is my personal view.
> variant until complete and then mark it "published". The translations
> changes do not necessarily need to be "versioned" in the usual sense of
the
> word as their origin is always the master which is versioned.
.....
> complete. In the latter case if the master is English and the variant
> French, then the English content will be versioned and "snapshots" of the
> French translation will be created intermittently along the way. In the
> former case it doesn't matter.
>
Since the group is still sorting out the meaning of configurations,
snapshots, baselines, etc. it is hard for me to agree or disagree with you.
I will say that your scenario sounds possible and probably works in many
'serial' development houses.
> In my opinion its all a matter of interpretation of the meaning of the
> variant - if it is a true variant and not a related resource, then it is
> simply a translation.
>
and, in your interpretation of the meaning of variant, a translation that is
achieved serially.