Delete: doc/repository.tex

}(Logical change 1.211)


git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@892 ce84e21b-d406-0410-9b95-82705330c041

1 files changed, 0 insertions, 35 deletions

diff --git a/doc/repository.tex b/doc/repository.tex
deleted file mode 100644
index 2068d2432..000000000
--- a/doc/repository.tex
+++ /dev/null
@@ -1,35 +0,0 @@
-\documentclass[11pt]{article}
-
-\title{Bcfg2 Repository Design}
-\author{Narayan Desai \\ desai@mcs.anl.gov}
-
-\setlength{\oddsidemargin}{0in}
-\setlength{\evensidemargin}{0in}
-\setlength{\topmargin}{0.0in}
-\setlength{\headheight}{0in}
-\setlength{\headsep}{0.5in}
-\setlength{\textwidth}{6.5in}
-\setlength{\textheight}{8.5in}
-\setlength{\parskip}{0.05in}
-
-\begin{document}
-\maketitle
-
-The BCFG repository is the storage depot for all components of client
-configurations. In BCFG1, this depot was composed of several SQL
-database tables and a filesystem hierarchy, composed of several types
-of data. 
-
-One of the high-level features desired from BCFG from the start was
-the ability for configuration changes, acquired through some automated
-mechanism, to be correctly installed into the configuration
-repository.  While using this ad-hoc repository, the underlying
-structure of data made automatic inclusion of new configuration
-fragments difficult. To address this problem, we have redesigned the
-repository to allow better data access and update semantics. 
-
-\section{Why is an ad-hoc repository problematic?'}
-
-\section{Design}
-
-\end{document}
\ No newline at end of file