Background: versioncontrol_project has a packaging script that currently uses "cvs export" directly. If we can have a public API function for that, the packaging script would be instantly version control system independent.
Thus, we should add an optional "export" function to the API. Existing similar functionality in versioncontrol_get_file_copy() might be considered (off-topic: why didn't anybody tell me about that crappy name? versioncontrol_copy_file() would make more sense?) and I guess versioncontrol_export_directory($repository, $directory_item, $target_path) makes for a workable function name.
Theoretically it would be possible to implement versioncontrol_export_directory() with a mixture of a recursive versioncontrol_get_directory_contents() and a series of versioncontrol_get_file_copy() calls, but a dedicated "export" function has two main advantages: a) speed, and b) preservation of the file's mtime - at least in CVS, hopefully all of the VCSes export their files with nice timestamps. "export" should also be easy to implement for all VCSes, even for Git which only offers a "git archive --format=tar" command (which can be piped back into files with "tar -x".)
Comments
Comment #1
sdboyer commentedSorry, so the one thing I missed here is the _why_ - what's the packaging script doing exports for? That'd bear on why timestamp preservation is so crucial. I suppose the question is more targeted at dvcs systems, where you get a wc along with a repo by default. git could just clone, bzr could do one of those shallow checkout things...
Regardless of that, though, I'd agree - it's worth implementing this.
Comment #2
jpetso commentedThe packaging script mainly needs a directory that's cleared of VCS directories like "CVS" or ".svn", because we don't want those to be packaged in the release tarball. That's less of a problem with Git & Co. as they only store all the "invisible" repository information in a single directory at top-level, but anyways it's either deleting those directories manually or using the export command provided by the VCS.
We can get rid of the dependency on timestamps by implementing #381956: Mark project releases as "to be updated" only if pushes happen there, so it's really just the VCS's private directories.
Comment #3
sdboyer commentedHmm. I know this isn't your stuff originally, but...
tar --exclude-vcsseems a LOT simpler.
Comment #4
jpetso commentedWorks also for remote repositories? :P
(Besides, that option is not even documented in "man tar".)
Comment #5
sdboyer commentedWhat version of tar? I've got it on my gentoo box (1.21) and my suse box (1.19), in both the man pages and --help.
I think the problem might just be that I initially misconstrued the context all this is happening in: that export needs to happen, regardless, to build a tarball, because we can't assume that a repo server is going to just have checkouts sitting around. I was operating under the silly assumption that there WERE checkouts sitting around, but that we were re-exporting somewhere else instead of just tarballing the existing checkouts and ignoring the vcs dirs. sorry :)
Comment #6
jpetso commented$ tar --version
tar (GNU tar) 1.20
Copyright (C) 2008 Free Software Foundation, Inc.
As shipped by (K)Ubuntu. Documented are --exclude=PATTERN and --exclude-from=FILE, but --exclude-vcs (even though it works) is not in the manpage.
Comment #7
jpetso commentedI've got the API module part done (function with apidox), need to have an example implementation though (for CVS) to make sure it can work as intended, and also an example implementation for the FakeVCS backend is required. So, assigning to myself, but not committing yet.
Comment #8
jpetso commentedFinally got around to finishing it up. Committed, along with an implementation for the CVS backend and live usage in versioncontrol_release. That should pretty much finish up 6.x-1.x feature-wise, RC1 must be really close now.