in reply to RFC: proposed new module VCS::Lite

This module provides the functions normally associated with a version control system, but without needing or implementing a version control system.

It looks to me like this module implements a version control system.

Using an array as your base object seems really bizarre to me. VC systems normally work on versioning a single "thing." That thing could be represented as an array, but there's no reason for a user to know that.

Replies are listed 'Best First'.
Re: Re: RFC: proposed new module VCS::Lite
by rinceWind (Monsignor) on Dec 18, 2002 at 17:23 UTC
    It looks to me like this module implements a version control system.
    I suppose you could take that view, much as DBD::SQLLite implements an RDBMS. Anyway, there are many things that a VC system does that I have no intention of implementing for VCS::Lite. These include an audit trail, change history, development streams, access control, check-out locking and unlocking, labels (aggregation of specific revisions of multiple objects). I can see the potential for another module in the VCS:: namespace which does implement a full VCS, or perhaps a software layer sitting above CVS, P4, PVCS, etc.
    Using an array as your base object seems really bizarre to me.
    There is a reason for this. A source file is a list of lines of text. Diff, patch and merge operate at the level of lines. Thinking about this polymorphically, the concept is really an array, and if you take a look at Algorithm::Diff, you will see that this module works on arrays.

    The naive user of the module who is working with text files, does not need to realise that the underlying object is an array. Thanks, Perrin for the feedback. I need to restructure the pod to make this clear - go through a simple worked example with text files; only afterwards deal with other types of array.

    This approach overcomes the difficulty that traditional VC systems have with binary files. If the programmer can supply a representation of a binary file as an array, it should be possible to do merges on binary files, given the rules for combining changes.

[reply]
      I don't tend to think of files as lists of lines. The line separator is totally arbitrary and I always slurp files into scalars. I think you should work with scalars and just split them into arrays when you need to feed them to Algorithm::Diff.

      I also don't think that working with arrays will make a difference to binary files. Binary diff utilities do exist, and I believe they just treat the file as a stream of bytes and use offsets.

[reply]
        Binary diff is trivially a special case of line oriented diff if you just change the definition of a line from "an arbitrarily long sequence of bytes terminated by the line separator" to "a single byte".

        Makeshifts last the longest.

[reply]
        I guess my VMS background is showing here (the VMS concept of a file is a record stream, not a byte stream). Besides, the diamond <> operator works on lines unless you change $/.

        In terms of binary files, I was thinking of RTF or word documents - something for which insertion and deletion could be valid operations.

        You are right about binary files generally, as without insertion/deletion, Algorithm::Diff is not appropriate. However, there's no reason not to use the same API (objects, diff, patch, merge) to do in-situ comparison. This can be achieved by subclassing VCS::Lite and providing some new methods.

[reply]

In Section Meditations