Hi, The fix appears to be working. The dump shrank with a few hundred revisions. Thanks!
The UUID is (AFAIK) used by the clients to identify the repository on the server. The generation of a new dump should in most cases result in a new UUID (At least I think it is rare that an existing WC out in the field would be possible to relocate to the new dump when it has been loaded). The md5:s on the other hand seem more tricky. When I load/dump, they aren't generated. In essence it seems that if the checksums are missing, they'll stay missing. The SvnDumpTool has the option the re-generate the checksums, but it can't handle that they are missing from the start. Almost a Catch-22, sigh! Best regards, /Micke (Anyone with a .NET filter hack? I've got 710*2 revisions with dummy Adds and Deletes.) Dirk wrote: > Hello Micke, > > I have added a fix for your first point. For the second issue, I don't > have any idea about the UUID and the MD5. Is doesn't seem to be really > necessary? A quick look into the SvnDumpTool also shows, that at least > the UUID is optional. > > If we put a UUID into the dumpfile, should it be a random generated one, > or should the user specify it on the command line? > > Best regards > dirk > > Micke schrieb: >> Hi! >> >> I've just tried a conversion of our latest product. Went smooth and >> looks good. Some quirks though: >> >> * Some Adds gets an extra initial empty line in the log messages. This >> seems to break the construction of changesets. Not all Adds with log >> messages but quite a large percentage. Adds with empty log messages get >> treated OK and bundle up with Modifys into changesets. >> >> * To move folders around, I tried to push the dump through SvnDumpTool. >> Initially it complained about a missing UUID. Added that by hand. Then >> it complained about "Text-content-md5", which as far as I could tell was >> missing in the revision indicated. It still failed after a load/dump >> cycle. >> >> I had planned to merge my old private branches with the new dump using >> SvnDumpTool, but that will obviously have to wait. >> >> Has anyone else tried SvnDumpTool (http://svn.borg.ch/svndumptool/) on >> vss2svn output? >> >> * The dump is full with .NET's test Add/Delete pairs. Has someone >> written a hack to filter them out? >> ----------------------- >> Revision-number: 4 >> .... >> svn:log >> V 97 >> >> Temporary file created by Visual Studio .NET to detect Microsoft Visual >> SourceSafe capabilities. >> ----------------------- >> Node-path: trunk/xxxx/~sak2d7a1b8b01c543f8.vcproj >> Node-kind: file >> Node-action: add >> Prop-content-length: 10 >> Text-content-length: 0 >> Content-length: 10 >> >> PROPS-END >> ----------------------- >> Node-path: trunk/xxxx/~sak2d94555e01c543f8.vcproj >> Node-action: delete >> ----------------------- >> >> (also note the extra empty line before the log message) >> >> Keep up the good work! >> /Micke >> >> _______________________________________________ >> vss2svn-users mailing list >> Project homepage: >> http://www.pumacode.org/projects/vss2svn/ >> Subscribe/Unsubscribe/Admin: >> http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org >> >> Mailing list web interface (with searchable archives): >> http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user >> >> >> >> > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
