mvdzwaan Posted December 9, 2011 Report Share Posted December 9, 2011 After some initial troubles getting our plastic 3...(32) repositories to plastic 4 (see other thread) my final fast-export + fast-import scripts are working fine. I get correctly processed messages on all repositories and everything seems fine when showing branch explorer, branches, changesets and items. However when I checkin a new changeset is created with changeset id 1, instead of (lastid+1). If I look in my rep database, in the table changeset I see iobjid ichangesetid fidbranch fidrootrevision iparentid scomplete 5 0 3 4 -1 T 111 1 3 63 0 T 124 2 3 116 1 T ... and so on... 6214 142 3 6202 141 T 6225 1 3 6217 142 T This leads to all kinds of strange behaviour within Plastic. It seems plastic uses a per repository 'last-changeset-id' somewhere (have looked but did not find) to get the next changeset number, and this variable is not set on fast-import. Is there a fix for this ? Either a fast-import fix, or a way to fix this within the database itself ? Link to comment Share on other sites More sharing options...
psantosl Posted December 9, 2011 Report Share Posted December 9, 2011 On start up plastic will calculate the "last cset" and use it to work with... It does a "select max" to get it. :? Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 9, 2011 Author Report Share Posted December 9, 2011 On start up plastic will calculate the "last cset" and use it to work with... It does a "select max" to get it. :? That would be the correct way to implement it in this database (as per the db independency you don't use constraints/identity etc.). But as the copy/paste of my changesets table shows this appears not to be the case. Maybe the select max(ichangesetid) has additional where statements which have not met by the imported changesets ? Link to comment Share on other sites More sharing options...
psantosl Posted December 9, 2011 Report Share Posted December 9, 2011 We're looking into it. There are two things we can do: 1- Wait till we fix it 2- Fix the cset numbers on the db (being very careful with the "parent cset id"). Link to comment Share on other sites More sharing options...
Olaf Kober Posted January 5, 2012 Report Share Posted January 5, 2012 This issue is not fixed in version 4.0.237.7. On start up plastic will calculate the "last cset" and use it to work with... It does a "select max" to get it. :? The key here is "on startup"... Following workaround did it for me: fast import your repository restart your plastic server checkins will create correct changeset numbers Link to comment Share on other sites More sharing options...
mvdzwaan Posted January 5, 2012 Author Report Share Posted January 5, 2012 This issue is not fixed in version 4.0.237.7. The key here is "on startup"... Following workaround did it for me: fast import your repository restart your plastic server checkins will create correct changeset numbers I will give this a try this weekend, would be great if this is the solution (I do not doubt you but still have to test it myself). It would also allow for an easy explanation. The plastic server does use the select max statement as psantosl mentioned but only does this on startup and than keep a cached variable for the new changeset number. In any case, thank you very much ! Link to comment Share on other sites More sharing options...
mvdzwaan Posted January 8, 2012 Author Report Share Posted January 8, 2012 Wanted to check, plastic was still running in a vm from my last attempt, but the server had been restarted due to windows updates. I just did a quick checkin and the numbering was ok. Maybe this should be added to the 3.0 to 4.0 migration guide ? Link to comment Share on other sites More sharing options...
manu Posted January 9, 2012 Report Share Posted January 9, 2012 Hi all, we will fix this issue soon, until that happens you can restart the server after the fast-import operation. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.