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

sdboyer’s picture

Sorry, 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.

jpetso’s picture

The 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.

sdboyer’s picture

Hmm. I know this isn't your stuff originally, but...

tar --exclude-vcs

seems a LOT simpler.

jpetso’s picture

Works also for remote repositories? :P
(Besides, that option is not even documented in "man tar".)

sdboyer’s picture

What 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 :)

jpetso’s picture

$ 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.

jpetso’s picture

Assigned: Unassigned » jpetso

I'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.

jpetso’s picture

Status: Active » Fixed

Finally 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 8d3cb4b on 6.x-1.x, repository-families, drush-vc-sync-unlock by jpetso:
    #381540 by jpetso: Introduce versioncontrol_export_directory(). Also,...

  • Commit 8d3cb4b on 6.x-1.x, repository-families by jpetso:
    #381540 by jpetso: Introduce versioncontrol_export_directory(). Also,...