Thanks Mike, happy to help if I can! :-)
Agreed, #2 is the best viable option.
I would not want to dictate the name for the user. I suggest a config item
that states the workspace name to use.
Providing a default name is nice, such as ${user}-${hostname}-maven.
User-hostname is a great and common base Perforce workspace naming scheme,
with additional qualifiers (such as the maven suffix) as necessary to
"uniquify" per machine.
I would not delete the workspace for a few reasons. The main reason is the
workspace is the "Perforce have list". So if it takes 20 minutes to do a
full sync, deleting the workspace causes a 20 minute sync each time.
Keeping the workspace reduces the sync time to the seconds/few minutes it
takes to get the changed files since the last sync. (this is one of the
many great features of Perforce - its speed!). This will help immensely
with Continuous Integration on large projects by minimizing the sync time.
So yes, I would make step 1 create or update the workspace spec with the
needed values. This also allows the user to config other items (rmdir,
compress, etc.) in the spec without developers (that's you!! ;-) having to
implement more settings in Maven plugin.
I would consider this Maven workspace spec "not temporary", but instead a
regularly used workspace.
-----Original Message-----
From: Mike Perham [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 10:24 PM
To: scm-dev@maven.apache.org
Subject: RE: [jira] Commented: (SCM-79) Add remaining operations to Perforce
provider
Thanks for your help, Jeff. It's good to have another Perforce user around.
One thing to remember is that _everyone_ needs this functionality, not just
the build machine. Anyone who is going to make a release needs to be able
to do this and if any developer can issue a release of their own module, I
don't want to force them to create a custom clientspec just to complete the
task, even if it's just a one-time task. That's why I think (1) will not
scale enough.
I would think something like this might be ugly but doable in an automated
fashion:
1. Create temp maven clientspec ${username}_maven with a single mapping:
Root:
${checkout_target}
View:
//depot/path/to/maven/project/... //${username}_maven/...
2. Sync the clientspec
p4 -c${username}_maven sync
3. Run the maven build in the directory.
4. Delete temporary clientspec?
p4 client -d ${username}_maven
All of this would hopefully be automated by the release plugin. The problem
I foresee is step 4. Checkout would require a cleanup operation unless we
made step 1 create a new or update an existing temp clientspec. Does this
seem reasonable to you? Do you have a better suggestion for auto-naming the
temp clientspec? Maybe hostname instead of username?
mike
-----Original Message-----
From: Jeff Jensen [mailto:[EMAIL PROTECTED]
Sent: Mon 11/28/2005 7:35 PM
To: scm-dev@maven.apache.org
Cc:
Subject: RE: [jira] Commented: (SCM-79) Add remaining operations to
Perforce provider
There is no "export" thing. "AltRoots" is the closest you get, but it is
still workspace spec specified.
So something else is in order...I see a couple of variations on an idea:
creating/updating a workspace on the fly with the correct values is pretty
easy.
1. Create a config option that names the existing workspace spec to use for
the CI build. This then assumes the user has correctly created one.
2. Create a config option that names the workspace spec it creates to use
for the CI build. This then creates/updates the spec.
The command then uses the named workspace spec for the sync.
-----Original Message-----
From: Mike Perham [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 4:34 PM
To: scm-dev@maven.apache.org
Subject: RE: [jira] Commented: (SCM-79) Add remaining operations to Perforce
provider
> - can you add checkouted files in a list in checkout consuler like we
> do it in svn provider?
I added this and attached an 'svn diff' patch to the issue. I also attached
a patch to fix several lingering issues with the commands -
'release:prepare' should work fully now.
> - can we checkout files in a specified directory (not only in working
> directory defined in Perforce configuration)? Continuum doesn't allow
> for the moment checkout in an other directory than continuum working
> directory.
I see why you are asking for this now. release:perform requires this
support since it checks out the tagged code into target/checkout. I don't
know how to cleanly do this in Perforce. I will have to think about it but
it's going to be ugly unless they have some sort of 'export' command that I
don't know about.
http://jira.codehaus.org/browse/SCM-79
mike
