Re: Anything out there to help organize all this into a nice repo?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Doug,

I do not know of any tooling for cvs that does what you
desire.

I think it is probably antithetical to the desire that a
'cvs checkout -D "timestamp"' would return the state of the
repository at a given time rather than the state of the
original sources at a given time.

As you have noted, the vendor branch is the exception in
that it tries to track the times of files from a third
party.

If your desire and intent is to populate an initial
repository from multiple sources and from that point do
things in the normal manner of cvs, then you may wish to
consider building up a tree of files using raw rcs commands.

The 'ci' command accepts a '-d[date]' flag that would
preserve the timestamps you desire and typically will start
with version 1.1. You could even preserve author userids
using the '-wwho' switch.

        -- Mark

Doug Lee <address@hidden> writes:

> I doubt such a tool exists as what I'm about to describe,
> but I'd sure love to be wrong.
> 
> I want to collect a lot of versions of a lot of files into
> a nice, clean CVS repository, preferably in which the
> version numbers go 1.1, 1.2, 1.3, etc., instead of using a
> vendor branch (minor). I do want the commit dates to
> reflect the file dates of the various versions though, and
> "cvs import" is the only way I can find to do that without
> hand-editing the repo files. I want the revisions to go in
> chronological order.
> 
> Unfortunately, by now, the various versions of a given
> file can be in any of the following places:
> 
> 1. A directory somewhere (we can assume it'll be online
> and accessible at the time this major process is run).
> 
> 2.  An archive file (zip, generally).
> 
> 3. Another CVS repository file, because I tried to do this
> with a bunch of Perl and bat files last December or so but
> never got finished, and further versions got created since
> then without CVS being used to manage them... so there are
> versions in the old CVS repo that got erased out on the
> network that I'd want to include in this master
> repository.
> 
> 4. Any of the above 3 places with a different file name,
> because some of these things got renamed during their
> earlier lives.
> 
> Any versions pulled from a CVS repo (items 3 and 4 above)
> should keep their log entries, commit dates, and any
> tags/branches. A tag or branch name should obviously be
> made to point to the new revision number in the final repo
> file.
> 
> Finally, since many copies of a given file may be
> identical but might not always share the same date/time,
> the final repo should contain only one copy of such a
> subset and should have as its commit date the oldest file
> date found. (I suppose if a CVS version with a log and/or
> tag/branch names is part of such a subset, the CVS
> version's log/branch/tag info should be included; but the
> oldest file date should still prevail if it's older than
> the CVS commit date found.)
> 
> 
> Again, I know I'm shooting for the moon here...but if
> anyone has developed or worked on anything like this, I'm
> all ears. My December attempt involved running a few
> home-grown DOS-box utilities to create full-path file
> lists in chronological order within each name, a lot of
> global replace commands to reformat the output of that, a
> Perl script to generate a batch file to runn a lot of CVS
> and copy commands, and finally a run of that batch file.
> The batch file generated by the Perl script constructed
> and cvs-imported N instances of a sandbox, where N was the
> largest number of revisions found of any single file;
> thus, each successive import actually made fewer changes,
> until the last one(s) which might only change one file in
> the repository. I had to handle the zips ahead of time,
> and I have no provision at all for pulling stuff from
> another CVS repo into this one. My Perl script did have a
> way of letting me group file names into a single set
> though, so I could deal with case 4 above fairly well (I
> can't remember how I handled file name upper/lower-case
> issues though; this is Windows, so case differences in
> file names should be ignored).
> 
> Thanks in advance for any info.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAwVBB3x41pRYZE/gRAuDfAKCjMUtuEPW931SSkqZPoFYF5Wg5iACgxWS5
yXkyXN/YGa10484AGgoiIv0=
=nAKR
-----END PGP SIGNATURE-----