This was causing test failures because die was exiting 255.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-cvsserver used checkout-index internally for commit and annotate.
Since a work tree is required for this to function now, this was
breaking. Work around this by defining GIT_WORK_TREE=. in the
appropriate places.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were many operations that did not notice and report errors
to the CVS client, which would have resulted in corrupt working
tree.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Other code assumes that this is initialized, so do it
even if there were no arguments given.
Signed-off-by: Dirk Koopman <djk@tobit.co.uk>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Embarrassing bug number two in my options patch.
Also enforce that --export-all is only ever used together with an
explicit whitelist. Otherwise people might export every git repository
on the whole system without realising.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Embarassing bug number one in my options patch.
Since the code for --base-path support rewrote
the cvsroot value after comparing it with a possible
existing value (i.e. from pserver authentication)
the check always failed.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git-cvsserver understand some options inspired by
git-daemon, namely --base-path, --export-all, --strict-paths.
Also allow the caller to specify a whitelist of allowed
directories, again similar to git-daemon.
While already adding option parsing also support the common
--help and --version options.
Rationale:
While the gitcvs.enabled configuration option already
offers means to limit git-cvsserver access to a repository,
there are some use cases where other methods of access
control prove to be more useful.
E.g. if setting up a pserver for a collection of public
repositories one might want limit the exported repositories
to exactly the directory this collection is located whithout
having to worry about other repositories that might lie around
with the configuration variable set (never trust your users ;)
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The path submitted with the Root request has to be absolute
(cvs does it this way and it may save us some sanity checks
later)
If multiple roots are specified (e.g. because we use
pserver authentication which will already include the
root), ensure that they say all the same.
Probably neither is a security risk, and neither should ever
be triggered by a sane client, but when validating
input data, it's better to be save than sorry.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since this is a trivial variation of the general pserver
authentication, there is really no reason not to support
it.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the per-method enable logic disables the access, we should
not even look at the global one.
git-cvsserver.perl | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
After we send I HATE YOU we should probably exit and not happily
continue with I LOVE YOU and further communication.
Most clients will probably just exit and ignore everything we
send after the I HATE YOU and it is not a security problem
either because we don't really care about the user name anyway.
But it is still the right thing to do.
[jc: with a minor fixup to its exit code...]
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change the configuration parser so that it ignores
everything except for ^gitcvs.((ext|pserver).)?
This greatly reduces the risk of failing while
parsing some unknown and irrelevant config option.
The bug that triggered this change was that the
parsing doesn't handle sections that have a
subsection and a variable with the same name.
While this bug still remains, all remaining
causes can be attributed to user error, since
there are no defined variables gitcvs.ext and
gitcvs.pserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We can't unconditionally assign revision 1.1 to
newly added files. In case the file did exist in the
past and was deleted we need to honor the old
revision number.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fl/cvsserver:
config.txt: Add gitcvs.db* variables
cvsserver: Document the GIT branches -> CVS modules mapping more prominently
cvsserver: Reword documentation on necessity of write access
cvsserver: Allow to "add" a removed file
cvsserver: Add asciidoc documentation for new database backend configuration
cvsserver: Corrections to the database backend configuration
cvsserver: Use DBI->table_info instead of DBI->tables
cvsserver: Abort if connect to database fails
cvsserver: Make the database backend configurable
cvsserver: Allow to override the configuration per access method
cvsserver: Handle three part keys in git config correctly
cvsserver: Introduce new state variable 'method'
Conflicts:
Documentation/config.txt
CVS allows you to add a removed file (where the
removal is not yet committed) which will
cause the server to send the latest revision of the
file and to delete the "removed" status.
Copy this behaviour.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only send a modified response if the client sent a
"Modified" entry. This fixes the case where the
file was locally deleted on the client without
being removed from CVS. In this case the client
will only have sent the Entry for the file but nothing
else.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Martin Langhoff <martin@catalyst.net.nz>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't include the scheme name in gitcvs.dbdriver, it is
always 'dbi' anyway.
Don't allow ':' in driver names nor ';' in database names for
sanity reasons.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
DBI->table_info is portable across different DBD backends,
DBI->tables is not.
Limit the output to objects of type TABLE.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Currently all calls to the database backend make no
error checking or handling at all. At least abort
if the connection to the database failed since
there is really no way we could do anything useful
after that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make all the different parts of the database backend connection
configurable. This adds the following string configuration variables:
- gitcvs.dbdriver
- gitcvs.dbname
- gitcvs.dbuser
- gitcvs.dbpass
The default values emulate the current behavior exactly for
backwards compatibility.
All configuration variables can also be specified for a specific
access method (i.e. in the form gitcvs.<method>.<var>)
The dbdriver/dbuser/dbpass variables are added for completness.
No other backend than SQLite is tested yet.
The dbname variable on the other hand is useful with this backend
already (to not discriminate against other possible backends
it was not splitted in dbdir and dbfile).
Both dbname and dbuser support dynamic variable substitution where
the available variables are:
%m -- the CVS 'module' (i.e. GIT 'head') worked on
%a -- CVS access method used (i.e. 'ext' or 'pserver')
%u -- User name of the user invoking git-cvsserver
%G -- .git directory name
%g -- .git directory name, mangled to be used in a filename,
currently this substitutes all chars except for [\w.-]
with '_'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow to override the gitcvs.enabled and gitcvs.logfile configuration
variables for each access method (i.e. "ext" or "pserver") in the
form gitcvs.<method>.<var>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be used in the form gitcvs.<method>.<var>
but this patch doesn't introduce any users yet.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$state->{method} contains the CVS access method used,
either 'ext' or 'pserver'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit: Also print the old revision similar to how cvs does it and
prepend a line stating the filename so that one can actually
understand what happened when commiting more than one file.
status: Fix the RCS filename displayed. The directory was
printed twice.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Submit some additional messages to the client on commit and update.
Inspired by the standard CVS server though a little more terse.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using Update-existing leads to the client forgetting about the "locally
modified" status of the file which can lead to loss of local changes on
later updates.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config option gitcvs.allbinary may be set to force all entries to
get the -kb flag.
In the future the gitattributes system will probably be a more
appropriate way of doing this, but that will easily slot in as the
entries lines sent to the CVS client now have their kopts set via the
function kopts_from_path().
In the interim it might be better to not just have a all-or-nothing
approach, but rather detect based on file extension (or file contents?).
That would slot in easily here as well. However, I personally prefer
everything to be binary-safe, so I just switch the switch.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commithash for updating the ref is obtained from a call to
git-commit-tree. However, it was returned (and stored) with the
trailing newline. This meant that the later call to git-update-ref that
was trying to update to $commithash was including the newline in the
parameter - obviously that hash would never exist, and so git-update-ref
would always fail.
The solution is to chomp() the commithash as soon as it is returned by
git-commit-tree.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "ci" codepath lockless by following the usual
"remember the tip, do your thing, then compare and swap at the
end" update pattern using update-ref. Incidentally, by updating
the code that reads where the tip of the head is to use
show-ref, it makes it safe to use in a repository whose refs are
pack-pruned.
I noticed that other parts of the program are not yet pack-refs
safe, but tried to keep the changes to the minimum.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver is analogous to git-receive-pack; a checking from a cvs
client to a central server is like a git-push from a working repository.
Therefore it's nice to use the same access control (and email sending)
that a receive-pack would perform.
This patch tests for an executable update hook; if it is it is run with
the ref being updated and the old and new hashes as normal. If the
update hook returns an error code the update is aborted and the ref is
never updated. The cvsserver returns "error 1" to the client to signal
there was an EPERM error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a repository was checked out via git-cvsserver and then later a new
file is added to the git repository via some other method; a CVS update
wasn't fetching the new file.
It would be reported as a new file as
A some/dir/newfile.c
but would never appear in the directory.
The problem seems to be that git-cvsserver was treating these two cases
identically, as "A" type results.
1. New file in repository
2. New file locally
In fact, traditionally, case 1 is treated as a "U" result, and case 2
only is treated as an "A" result. "A", should just report that the file
is added locally and then skip that file during an update as there is
(of course) nothing to send.
In both these cases there is no working revision, so the checking for
"is there no working revision" will return true. The test for case 2
needs refining to say "if there is no working revision and no upstream
revision". This patch does just that, leaving case 1 to be handled by
the normal "U" handler.
I've also updated the log message to more accurately describe the
operation. i.e. that "A" means that content is scheduled for addition;
not that it actually has been added.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, cvs add / cvs commit echoes back to the client
the correct file version (1.1) so that the file in the checkout
is recognised as up-to-date.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
if the SHA1 of our head matches the last SHA1 seen in the DB, avoid further
processing.
[jc: an "Oops, please amend" patch rolled in]
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the same vein as 8336afa563,
this fixes the the RCS merge to git-merge-file conversion in
commit e2b70087.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (42 commits)
git-svn: correctly handle packed-refs in refs/remotes/
add test case for recursive merge
git-svn: correctly display fatal() error messages
git-svn: allow dcommit to take an alternate head
git-svn: enable logging of information not supported by git
Clarify fetch error for missing objects.
Move Fink and Ports check to after config file
shortlog: fix segfault on empty authorname
shortlog: remove "[PATCH]" prefix from shortlog output
Make sure the empty tree exists when needed in merge-recursive.
Don't use memcpy when source and dest. buffers may overlap
no need to install manpages as executable
Documentation: simpler shared repository creation
shortlog: fix segfault on empty authorname
Add branch.*.merge warning and documentation update
Fix perl/ build.
git-svn: use do_switch for --follow-parent if the SVN library supports it
Fix documentation copy&paste typo
git-svn: extra error check to ensure we open a file correctly
Documentation: update git-clone man page with new behavior
...
Now that we have git-merge-file, an RCS merge lookalike, we no longer
need it. So long, merge, and thanks for all the fish!
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At some point between v5.6 and 5.8 Perl started to assume its input,
output and filehandles are UTF-8. This breaks the counting of bytes
for the CVS protocol, resulting in the client expecting less data
than we actually send, and storing truncated files.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tonight I found a git-cvsserver instance spending a lot of time in
disk IO while trying to process operations against a Git repository
with >30,000 objects contained in it.
Blowing away my SQLLite database and rebuilding all tables with
indexes on the attributes that git-cvsserver frequently runs queries
against seems to have resolved the issue quite nicely.
Since the indexes shouldn't hurt performance on small repositories
and always helps on larger repositories we should just always create
them when creating the revision storage tables.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, cvsserver showed always an 'U', sometimes even without a space
between the 'U' and the name. Now, the correct letter is shown, with a
space.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-update-ref writes into the lockfile, and renames it afterwards. Like
commit v1.3.0-rc3~22, it is not only cleaner, but also helps with shared
setups: every developer can have a different primary group; what matters
is that $GIT_DIR/refs/heads has to be writable by a group you are in.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, cvsserver barfed when you tried to check in files with a
multiline commit message.
That is what Argumentx is for... Argument: lines can be followed by
several Argumentx: lines, which means they should be appended.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Turns out that DBD::SQLite does not favour preparing statements which are
never executed. So, turn all 4 statements, which were prepared _always_,
into methods, like the other 12 prepared statements.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch defines $state->{prependdir} as the empty string, so that
quite a few warnings are avoided.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
