On Sat, Dec 27, 2008 at 07:20:31PM +0100, Romulo Goncalves wrote:
Stefan Manegold wrote:
On Sat, Dec 27, 2008 at 05:08:39PM +0000, Romulo Goncalves wrote:
Update of /cvsroot/monetdb/sql/src/server In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv19272
Modified Files: Tag: Nov2008 sql_schema.mx Log Message: It seems it is also broken in the stable... If you drop a constraint like a primary key make sure there are no dependencies on it...
Note: Do not propagate this check in... it was already done in the current branch...
Your instructions: – propagate to branch, but leave in HEAD cvs up -r<branch> MyPath/MyFile cvs up -j1.22 -j1.23 MyPath/MyFile cvs diff MyPath/MyFile cvs ci -m' backported bugfix from HEAD:
<original log message> identical checkin, expecting no conflicts during propagation ' MyPath/MyFile cvs up -A MyPath/MyFile
So lets learn that... Correct my steps if they are wrong... (in the current branch)
cvs update -rNov2008 -dP sql_schema.mx cvs update -j1.160 -j1.161 sql_schema.mx cvs diff sql_schema.mx (what should I expect here, think no diffs)
Well, the same diff as between r1.160 and r1.161, because that what the `cvs update ...` command before is supposed to apply to your checked out copy of sql_schema.mx from the Nov2008 branch, right? If there were no diff, then there was nothing to check in hereafter ...
cvs ci -m' backported bugfix from HEAD: If you drop a constraint like a primary key make sure there are no dependencies on it... identical checkin, expecting no conflicts during propagation ' sql_schema.mx cvs up -A sql_schema.mx
Would this work if the next time I need to do back porting?
Sure --- provided that the same patch works for both the development trunk and the release branch ...
My main point was that if the back-porting is done via such cvs commands as above, then there will (should) be no propagation conflicts.
Even better: first check whether the fix is also required for the latest release branch, and then check it in ONLY in the release branch! ... ;-)
What about new directories and new files?
Same as above --- in order of preference:
1) In case something needs to be changed (indentically) in both the latest release branch and the development trunk, then changed it in the release branch, ONLY (propagation will take care of the rest).
2) In case you accidently applied changes (incl. adding/deleting files and/or directories) in the development trunk, use the proper cvs commands to (preferably first undo them in the development trunk and then) back-port/re-apply them to the release branch.
In case of doubt about what to do or which cvs commands to use, see the documentation and/or feel free to ask ;-)
Stefan
Regards, Romulo
if the changes are identical (i.e., made using cvs commands), propagation will notice this and silently accept the identical changes (i.e., not try to do them again).
see also `man cvs` and pages 8-16 (in particular pages 13-15) of http://homepages.cwi.nl/~manegold/Presentations/MonetDBdevTTT.pdf
Stefan
U sql_schema.mx Index: sql_schema.mx =================================================================== RCS file: /cvsroot/monetdb/sql/src/server/sql_schema.mx,v retrieving revision 1.152.2.1 retrieving revision 1.152.2.2 diff -u -d -r1.152.2.1 -r1.152.2.2 --- sql_schema.mx 14 Nov 2008 13:48:40 -0000 1.152.2.1 +++ sql_schema.mx 27 Dec 2008 17:08:37 -0000 1.152.2.2 @@ -1695,6 +1695,8 @@ assert(l->h->next->type == type_int); if ((key = mvc_bind_key(sql, ss, kname )) == NULL) return sql_error(sql, 02, "cannot drop unknown constraint %s\n", kname);
if (!drop_action && mvc_check_dependency(sql, key->base.id, KEY_DEPENDENCY, NULL))return sql_error(sql, 02, "unable to drop constraint %s (there are database objects which depend on it)\n", key->base.name);
Monetdb-sql-checkins mailing list Monetdb-sql-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-sql-checkins
Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers