new provider (accurev) - isPersistCheckout

[lwoggardner <gr...@lastweekend.com.au>]

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.

AW: new provider (accurev) - isPersistCheckout

[Mark Struberg <st...@yahoo.de>]

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" <sc...@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.