Chip Turner wrote:
> J Robert Ray <jrray@imageworks.com> writes:
>
>
>>Hi folks,
>>
>>I just had a fellow dev point out to me that checkout by date doesn't
>>work in our repository (i.e. svn checkout -r {2004-10-01} http://...).
>>
>>We have been migrating from cvs on a project-by-project basis, and I
>>have been using cvs2svn to import slices of our cvs repository one at
>>a time.
>>
>>As a result, the dates of the revisions in our repository are not
>>strictly in chronological order:
>
>
> We do the exact same thing -- import portions at a time, subtree by
> subtree, and our revisions are no longer in chronological order,
> either.
>
> I don't see there really being a good solution short of renumbering a
> repo by date... but that could get really messy. Imagine this:
>
> /foo/bar - created on 09/12/04, r12
> /foo/bar/blip - imported from cvs, dates range from 01/01/01 to
> 01/01/03, r13 through r1000
>
> what revision should /foo/bar be created in, if the repo were
> restructured and sorted strictly by date? Or would its revision
> entirely disappear, perhaps being subsumed by the cvs import dirs?
This sequence of events:
09/12/04, r12: mkdir /foo/bar
01/01/01, r13: mkdir /foo/bar/blip [start of import]
...
01/01/03, r1000: [end of import]
could be resorted into this:
01/01/01, r12: mkdir /foo/bar [manufactured event, old date]
01/01/01, r13: mkdir /foo/bar/blip [start of import]
...
01/01/03, r1000: [end of import]
09/12/04, r1001: mv /foo/bar/blip /tmp
09/12/04, r1002: rm /foo/bar
09/12/04, r1003: mkdir /foo/bar [originally r12]
09/12/04, r1004: mv /tmp /foo/bar/blip
Renumbering commits (reassigning revision numbers) is not very
desireable, but it does seem possible to reorder the events to keep
things chronological, while preserving all the events. Maybe this last
point isn't important.
My first idea was to import into a temporary directory, and then move
into place, avoiding the rm+mkdir game, but that would make it
impossible to check the tree out from the real location from a point in
time during the import.
>
> Perhaps cvs2svn shouldn't be forging dates at all, instead storing
> original dates in a cvs2svn:date property or something... especially
> if code in svn is making an assumption that revision ordering and date
> ordering are the same.
I feel the commit date from cvs is an important piece of metadata and it
would be best to have the svn commit date match. Given that the goal is
to be able to checkout code based on date, it would be useless to not
have the original cvs commit dates. Or if they were stuffed in a
property, the original problem still applies.
- Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 14 05:08:26 2004