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.
