for these providers the "client spec", "workspace" etc IS the meta information.
ie by that definition "non persistent checkout" == "export". The difference being that the meta data isn't stored within the source tree so it doesn't get in the way of the tarball anyway The corollary with this approach is that you can't allow a checkout within a subdirectory of another checkout. It would have been cleaner IMHO to 1) enhance export to support relativePathProjectDirectory concept or move that concept to the repository. 2) add a repository flag - shouldUseExportForNonPersistentCheckout() 3) change the release plugin to test this flag, rather than setting something. All the downstream systems had to change to setIsPersistCheckout(true) in order to support Clearcase and Perforce properly which could have been avoided. The providers that don't have this issue would still not be required to implement export. Should I raise a JIRA (with patches) to suggest the above?. Alternatively we'll need to either change the default to "true" OR change the tcktests to use setPersistCheckout() appropriately. On Mon, 19 Jan 2009 10:47:35 +0000 (GMT), Mark Struberg <strub...@yahoo.de> wrote: > The export command is usually used to create a tarball or zip so there will > be no SCM meta information at all. > The command is btw not implemented in all scm providers (e.g. git doesn't > support exports natively). > > On the other hand (according to SCM-113) isPersistCheckout() is only about > removing the client spec after a normal checkout. > > LieGrue, > strub > > --- lwoggardner <gr...@lastweekend.com.au> schrieb am Mo, 19.1.2009: > >> Von: lwoggardner <gr...@lastweekend.com.au> >> Betreff: new provider (accurev) - isPersistCheckout >> An: "Scm dev" <scm-dev@maven.apache.org> >> Datum: Montag, 19. Januar 2009, 11:25 >> Hi all, >> >> As per my previous post I'm in the process of >> implementing an extended >> AccuRev >> provider. >> >> AccuRev, apparently like Perforce and Clearcase, keeps >> track of user >> checkouts >> in "workspaces". These workspaces are uniquely >> named across the repository, >> and >> the physical filesystem locations are not permitted to >> overlap. >> >> Consequently the release plugin's checkout to the >> target/checkout >> sub-directory >> is problematic. It looks like the >> "isPersistCheckout()" method from SCM-113 >> is >> intended to resolve this very issue, but I have a few >> questions on that. >> >> 1) Why is the default "false". >> - It appears that the previous behaviour was more >> equivalent to "true". >> - The tck-tests (eg the checkin/tag tck tests) assume by >> their behaviour >> that >> the default is "true". >> - The only downstream use that sets "false" is >> the release plugin. >> Everything >> else sets it explicitly to "true" (of course >> I can't search for things >> that >> don't set it explicitly, so there might be others) >> >> 2) What is the difference between isPersistCheckout == >> false, and the >> "export" >> command? >> >> - Both seem to extract a set of files to a directory, >> without the >> intention of >> updating or committing back. >> - It feels strange that downstream users have to set a >> flag in the >> provider >> repository which is otherwise "owned" by the >> provider. >> >> Thanks, >> Grant. > > >
