undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

cvsserver doc: database generally can not be reproduced consistently

Browse Source 
A regenerated git-cvsserver database is at risk of having different
CVS revision numbers from an incrementally updated database.  Mention
this in the the documentation, and remove an erroneous statement
to the contrary.

Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Matthew Ogilvie 2009-11-22 19:07:29 -07:00 committed by Junio C Hamano
parent 12fb25dce8
commit 2fdc0cfcd9
1 changed files with 15 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/git-cvsserver.txt
View File

@ -182,10 +182,9 @@ Database Backend
---------------- ----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to 'git-cvsserver' uses one database per git head (i.e. CVS module) to
store information about the repository for faster access. The store information about the repository to maintain consistent
database doesn't contain any persistent data and can be completely CVS revision numbers. The database needs to be
regenerated from the git repository at any time. The database updated (i.e. written to) after every commit.
needs to be updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the using 'git-cvsserver') the update will need to happen on the
@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting 'git-cvsserver' write access to the database file without granting
them write access to the directory, too. them write access to the directory, too.
The database can not be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
one branch of development, and after a 'git-merge' an
incrementally updated database may track a different branch
than a database regenerated from scratch, causing inconsistent
CVS revision numbers. `git-cvsserver` has no way of knowing which
branch it would have picked if it had been run incrementally
pre-merge. So if you have to fully or partially (from old
backup) regenerate the database, you should be suspicious
of pre-existing CVS sandboxes.
You can configure the database backend with the following You can configure the database backend with the following
configuration variables: configuration variables: