sdbm.pm #5

package VCP::RevMapDB::sdbm;

=head1 NAME

VCP::RevMapDB::sdbm - Persistant storage for id -> (name, rev_id) maps

=head1 SYNOPSIS

    use VCP::RevMapDB::sdbm;
    VCP::RevMapDB::sdbm->new( File => "/path/to/db_file.db" );

=head1 DESCRIPTION

By default, most VCP::Dest::* drivers keep track of the relationship
between the id field assigned by the (original) VCP::Source::* driver
and the final name and rev_id (or whatever fields are important to it)
in the destination repository so that the previous_id fields, which
refer to the original id, may be resolved when backfilling or branching.

The VCP::*::revml drivers do not do this; they do not need to resolve id
fields.

The intent for this file is to serve as a default; individual sites
should be able to write their own RevMapDB plugins so that they can, for
instance, store this state in a RDBMS table.  This is not quite offered
at this time; we need to add an option to the appropriate VCP::Dest::*
modules to allow the appropriate RevMapDB file to be loaded.

To write your own RevMapDB file, copy this file and alter it.

=for test_script t/01revmapdb_sdbm.t

=cut

$VERSION = 1 ;

use strict ;
use VCP::Debug qw( :debug );
use Fcntl;
use File::Spec;
use SDBM_File;
use VCP::Debug qw( :debug );

use base qw( VCP::RevMapDB );

use fields (
   'Hash',  ## The hash we tie
);

sub db_file {
   my VCP::RevMapDB::sdbm $self = shift;
   return File::Spec->catfile(
      $self->store_loc,
      "revmap.db"
   );
}


sub close_db {
   my VCP::RevMapDB::sdbm $self = shift;

   return unless $self->{Hash};

   $self->SUPER::close_db;

   $self->{Hash} = undef;
}


sub delete_db {
   my VCP::RevMapDB::sdbm $self = shift;

   return
      unless -e $self->store_loc && glob(
         $self->store_loc . "/*"
      );

   $self->SUPER::delete_db;
   $self->rmdir_store_loc;
}


sub open_db {
   my VCP::RevMapDB::sdbm $self = shift;

   $self->SUPER::open_db;
   $self->mkdir_store_loc;

   $self->{Hash} = {};

   my $fn = $self->db_file;

   tie %{$self->{Hash}}, "SDBM_File", $fn, O_RDWR|O_CREAT, 0660
      or die "vcp: $! while opening RevMapDB SDBM file '$fn'";
}


sub open_existing_db {
   my VCP::RevMapDB::sdbm $self = shift;

   $self->SUPER::open_db;
   $self->mkdir_store_loc;

   $self->{Hash} = {};

   my $fn = $self->db_file;

   tie %{$self->{Hash}}, "SDBM_File", $fn, O_RDWR, 0
      or die "vcp: $! while opening RevMapDB SDBM file '$fn'";
}


sub set {
   my VCP::RevMapDB::sdbm $self = shift;
   my $key = shift;

   warn "vcp: overwriting RevMapDB entry for ",
      $key,
      ".  Stale vcp_state in ", $self->store_loc, "?\n"
      if $self->{Hash}->{$key};

   $self->{Hash}->{$key} = $self->pack_values( @_ );
}


sub get {
   my VCP::RevMapDB::sdbm $self = shift;
   my ( $key ) = @_;

   my $v = $self->{Hash}->{$key};

   die "vcp: no RevMapDB entry for ",
      $key,
      "\n"
      unless $v;

   $self->unpack_values( $v );
}


=head1 LIMITATIONS

There is no way (yet) of telling the mapper to continue processing the
rules list.  We could implement labels like C< <<I<label>>> > to be
allowed before pattern expressions (but not between pattern and result),
and we could then impelement C< <<goto I<label>>> >.  And a C< <<next>>
> could be used to fall through to the next label.  All of which is
wonderful, but I want to gain some real world experience with the
current system and find a use case for gotos and fallthroughs before I
implement them.  This comment is here to solicit feedback :).

=head1 AUTHOR

Barrie Slaymaker <barries@slaysys.com>

=head1 COPYRIGHT

Copyright (c) 2000, 2001, 2002 Perforce Software, Inc.
All rights reserved.

See L<VCP::License|VCP::License> (C<vcp help license>) for the terms of use.

=cut

1