Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: point of time dump?
From: jblist@icloud.com
In-reply-to: <20160119232742.GA5560@gmail.com>
Date: Tue, 19 Jan 2016 16:44:36 -0700
Cc: users@subversion.apache.org
Content-transfer-encoding: quoted-printable
Message-id: <0712C5F0-2789-45E9-A396-60770203BF22@icloud.com>
References: <20160119195705.GA31590@gmail.com>
 <F590A341-B50E-48DC-B886-3B8347CFE40C@icloud.com>
 <20160119232742.GA5560@gmail.com>
To: Eric Antonio Maquiling <ericantoniomaquiling@gmail.com>


> On Jan 19, 2016, at 4:27 PM, Eric Antonio Maquiling =
<ericantoniomaquiling@gmail.com> wrote:
>=20
> On Tue, Jan 19, 2016 at 01:52:33PM -0700, jblist@icloud.com wrote:
>>=20
>> To present the code as a change over time, you have a couple of =
options. You
>> could perform the same export as above but do so for each revision of =
the
>> repository over the selected range. This could be automated creating =
separate
>> directories or folders for each revision. This would allow an =
intuitive way of
>> browsing the code base over time without the use of svn technology.
>>=20
>> If you need to present the actual changes, then using various options =
of the "svn log" command could show the deltas of each commit over the =
same range. Use of the '-c' option might allow for outputting each =
commit as a separate file through automation.
>>=20
>=20
>=20
>=20
> I was TOTALLY wrong in what it was they wanted.  More explantion from =
the
> managers reveiled this to me.  An outside agency wants to view the =
code
> (guessing some sort of audit).
>=20
> They want to see the code AND the changes to code (whatever file they =
want to
> see) over the course in time UP TO June of last year.  BUT not from =
June last
> year to present.
>=20
> Talked to a developer who is pretty good with SVN and he thought he =
had ideas
> but then turned out it won't work.
>=20
> I suggested they install Tortoise and they can view all the changes =
they want
> but the source code has to be outside the building and the network so =
it has to
> be presented something like a CD or DVD.
> --=20
> eric


Ok, this is still workable. The first option assumes that your auditors =
have no clue how to use SVN and would be fine with raw source code minus =
all the nice meta-data provided by subversion. The second option assumes =
your auditors are at least willing to use SVN tools to browse a =
repository.


Option 1) You will still need to automate the export of every revision =
from 1 to the end date you have in mind.

Something like this (choose your favorite scripting language):

for R in 1..X (where X is the revision from June of last year)
  svn export -r $R  foldername.$R
end-for

This will export each revision into its own folder, named with the =
revision number from the repository. You will lose all meta data with =
this method: Who changed what, and what the commit log was for each =
commit will be lost. Depending on how old and how big your repository =
is, this might exceed the capability of your local machine and the =
capacity of optical storage media.


Option 2) On the other hand, if your auditors are familar with =
subversion and would like a local COPY of the repository so that meta =
data are preserved, you might have better luck using "svnadmin dump =
-r1:X" to dump out the range of revisions up to X, or June of last year. =
Then use "svnadmin load" to create a new subset repository containing =
only the revisions in question. This duplicate, subset repository could =
be burned to optical media and browsed using tools such as Tortoise.