On Tue, 2005-02-15 at 00:55 +0100, Marcin Dalecki wrote: > On 2005-02-14, at 19:47, Mike Stump wrote: > > > On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote: > >>> Fine, i'll just keep all the non-snapshot tags for now. > >> > >> There's no reason why we have to keep all the tags in one place. > > > > Further, we can import them all, and then later remove, move or rename > > them and these things seem to be versioned(?). I can't imagine that > > the size of tags would matter, I think we should do that. We could > > even move old tags to a directory called old if we wanted to, to help > > sort out the chaff and reduce clutter while still allowing people > > doing archeology to be able to easily find them. It seems safer to > > import them all, and then remove them in the new system, as it seems > > to be trivial to restore any mistakes, while, if they go missing in > > the import, putting any tag back would be, uhm, hard. > > Hmm... What about the "trivial" strategy of automatic commit mirroring > for a sufficient > long time? I guess old information deflates in value pretty fast (maybe > about one year?). > Could be easier to implement. >
It's not easier to implement. Trying to translate cvs into changesets is not easy (though the reverse is), unless you do it the stupid way (IE not try to discover what is a copy and what isn't). So matching commit for commit won't give you good history. Especially on branches. We did convresion this way with bugzilla and it worked okay. I just translated the gnats database every so often. The more important part is that people feel comfortable using the tool. making the data all look right is the easy part :)
