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);
> >>            mvc_drop_key(sql, ss, key, drop_action);
> >>            res = stmt_none();
> >>    } break;
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Monetdb-sql-checkins mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/monetdb-sql-checkins
> >>
> >>
> > 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Monetdb-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers
> 
> 

-- 
| Dr. Stefan Manegold | mailto:[email protected] |
| CWI,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: +31 (20) 592-4212       |
| The Netherlands     | Fax : +31 (20) 592-4312       |

------------------------------------------------------------------------------
_______________________________________________
Monetdb-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Reply via email to