Hello. I'm writing regarding the behavior of cvs on the backuprecover-15 test case. The comments call it a 'failure case', which seems to mean 'the behavior is broken, but since we know what the behavior is, we'll make sure we don't change it accidently'.
# Note that backuprecover-15 is probably a failure case # If nobody else had a more recent update, the data would be lost # permanently # Granted, the developer should have been notified not to do this # by now, but still... We have a situation where we may have to quickly failover to a mirror which may be missing 5-10 minutes of data. In that case, it would be impractical to ensure that every engineer knows that they may lose data if they update. Consequently, I've written the attached patch to treat a workspace with a newer unmodified version of a file as an error. The test suite needs a few changes to pass; With the patch, cvs behavior in response to an admin command changes. Currently, if version 1.5 is removed via 'cvs admin -o', any tree with an unmodified version of 1.5 silently reverts to 1.4 at the time of next update. After the patch, cvs will complain at the time of next update. Consequently, a few tests which check the previous behavior need changes. I have a few questions: 1. Does anyone see any problems that this patch would cause? 2. Would cvs developers be interested in integrating this behavior? If so, I'll be happy to generate a real patch (ChangeLog entry, testsuite changes, GNU coding style, copyright assignment (if needed)), but I wanted to check for interest before I go through and do all the details. 3. Does anyone know of a better way to accomplish this? Thanks for your time, greg -- [EMAIL PROTECTED] | maintaining individual accountability http://docs.yahoo.com/info/values/
--- classify.c.old 2005-06-16 19:19:30.000000000 -0700 +++ classify.c 2005-06-16 22:52:13.000000000 -0700 @@ -341,7 +341,7 @@ } else { - /* The RCS file is a newer version than the user file */ + /* The RCS file version does not match the user file */ if (vers->ts_user == NULL) { @@ -354,19 +354,43 @@ error (0, 0, "warning: %s was lost", finfo->fullname); ret = T_CHECKOUT; } + /* if vers->tag is set, then we could be updating a file + on a branch, which if the file hasn't been modified on the + branch, could wind up being a lower version than our file + basically: + add 1.1 + tag -b foo + remove (dead 1.2) + add (1.3) + update -r foo (vn_rcs == 1.1, vn_user == 1.3) + (see resurrection tests) + */ else if (strcmp (vers->ts_user, vers->ts_rcs) == 0) { - - /* - * The user file is still unmodified, so just get it as well - */ - if (strcmp (vers->entdata->options ? - vers->entdata->options : "", vers->options) != 0 - || (vers->srcfile != NULL - && (vers->srcfile->flags & INATTIC) != 0)) - ret = T_CHECKOUT; - else - ret = T_PATCH; + if (((!vers->tag) || (0 == strcmp(vers->tag, "HEAD"))) + && (!vers->date) + /* comparing versions is only reliable if numdots is the same */ + && (numdots(vers->vn_user) == numdots(vers->vn_rcs)) + && (compare_revnums(vers->vn_user, vers->vn_rcs) > 0)) + { + ret = T_MODIFIED; + error (1, 0, "file '%s` has revision %s, but the repository only has %s\n", + finfo->fullname, vers->vn_user, vers->vn_rcs); + + } else { + + + /* + * The user file is still unmodified, so just get it as well + */ + if (strcmp (vers->entdata->options ? + vers->entdata->options : "", vers->options) != 0 + || (vers->srcfile != NULL + && (vers->srcfile->flags & INATTIC) != 0)) + ret = T_CHECKOUT; + else + ret = T_PATCH; + } } else if (No_Difference (finfo, vers)) /* really modified, needs to merge */
_______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs