Re: lockinfo
On 2005-05-09T11:25:06-0700, Mark D. Baushke wrote:
- empty/nonexistent lockinfo: everything should work as ever
- layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
- lockinfo contains
^a false
^a/b true
- checkout a should fail
- checkout b should work (i'm not too sure)
I believe CVS processes directories alphabetically depth-first. So, in
this case, b would also fail unless you explicitly did a
cvs checkout a/b
you are right, that's what i'm talking about when i wrote 'checkout b'
In point of fact, the addition of this new feature may be a good time to
alter how cvs works.
as long as i don't have to write it :)
If you are explicitly controlling checkout
behavior, then you could choose to non-fatally skip directories for
which you do not have permissions... it would be as if they were really
private to some other set of users and not even visible to the user
implicitly trying to check them out.
Than CVS internals really have to be changed. My little patch makes the
lock creation fail. When lock creation fails, CVS aborts the current
operation. One possible change: first lock all directories which are
going to be used. If all locks were successfully created, do the
checkout: somehow
if (start_recursion(lock..)){
start_recursion(checkout..)
start_recursion(unlock..)
}
Although it may be desirable to
force an error if the user explictly asked for a 'read-locked' directory
on the command line instead of just running into one during the checkout
process.
But as I said, that's exactly the behaviour when someone enforces 'dont
read (dont create locks)' with file system permissions.
Addition of this kind of 'read-lock' might be considered to be 'better'
than just use operating-system directory permissions.
It's not that elegant, but more flexible. And it works with all kinds of
file systems.
I still remain unconvinced that the current implementation of your patch
is desirable.
Since my patch is GPL, everyone is free to change it / ignore it. In
which direction do you would change it?
+Before the lock is created, the @file{loginfo} in CVSROOT is
The above line references `loginfo' instad of `lockinfo' which seems
wrong.
Because it is wrong :)
But I think I don't need to send a patch for that :)
I suspect that some mention that this is for read-locks instead of
dealing with promotable or write locks...
I thought write locks are an entire different ball game? But feel free
to correct me.
it also begs the question as to the correct name for this file being
'readinfo' instead of 'lockinfo' ...
As I wrote, anybody can change that.
Kendy
--
pgpKKxZXZH7Le.pgp
Description: PGP signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
lockinfo
Attached is a patch to current release which introduces a file
$CVSROOT/lockinfo. The file has the same properties as other *info files
in that directory.
Intended usage: Directories are read-locked before any read-operation is
done. A script (along the lines of contrib/cvs_acl.pl) can check whether
this read operation is allowed. This way read ACLs can be implemented.
Kendy
--
diff -u -r cvs-1.12.12/src/cvs.h cvs_my/src/cvs.h
--- cvs-1.12.12/src/cvs.h 2005-04-14 16:14:55.0 +0200
+++ cvs_my/src/cvs.h2005-05-03 16:44:52.837176991 +0200
@@ -163,6 +163,7 @@
#define CVSROOTADM_CONFIG config
#defineCVSROOTADM_HISTORY history
#defineCVSROOTADM_IGNORE cvsignore
+#define CVSROOTADM_LOCKINFOlockinfo
#defineCVSROOTADM_LOGINFO loginfo
#defineCVSROOTADM_MODULES modules
#define CVSROOTADM_NOTIFY notify
diff -u -r cvs-1.12.12/src/lock.c cvs_my/src/lock.c
--- cvs-1.12.12/src/lock.c 2005-04-14 16:13:26.0 +0200
+++ cvs_my/src/lock.c 2005-05-03 17:54:40.813153559 +0200
@@ -476,7 +476,23 @@
}
}
+int
+check_lock_info_proc(const char * rep, const char * filter, void * ud)
+{
+ const char * srepos = Short_Repository(rep);
+ char * cmdline = Xasprintf(%s %s, filter, rep);
+ run_setup (cmdline);
+ free(cmdline);
+ return(abs(run_exec(RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL |
RUN_SIGIGNORE)));
+}
+int
+check_lock_info(const char * xrep)
+{
+ int n;
+ n = Parse_Info (CVSROOTADM_LOCKINFO, xrep, check_lock_info_proc,
PIOPT_ALL, NULL);
+ return n;
+}
/*
* Create a lock file for readers
@@ -489,6 +505,11 @@
TRACE (TRACE_FUNCTION, Reader_Lock(%s), xrepository);
+if (check_lock_info(xrepository)){
+ error(0, 0, Lock Info failed);
+ return 1;
+}
+
if (noexec || readonlyfs)
return 0;
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
