[p4] Using current directory as client root?
Jeff Jensen
jjensen at apache.org
Sat Jan 19 12:18:21 PST 2008
When you write "artifacts", do you mean the final build artifacts, e.g.
.jars, .exes, etc., or do you also include .classes, .o, .obj, etc? Since
you wrote "entire build process", I infer you mean all of those.
I want to clarify because the "storage" of the component build/deployment
artifacts is a very typical requirement (e.g. the jars/wars/ears et al).
For most of my customer work, the build artifacts go to a "corporate
artifact repository", not kept in the build area.
I haven't ever encountered the need to keep intermediate files around in the
build area, especially for longer than the current build is in progress. If
you also require storage of the intermediate generated files, then that is a
different issue, of course! :-) And I assume a "workspace per codeline".
What I was getting at...it may be "far afield" of Perforce issues, but I ask
this question as sometimes a stated need is arbitrary vs a well thought
out/true business need. Effectively, since Perforce "manages" the workspace
for you, and, as part of that management, requires a defined workspace (i.e.
Perforce design inflicting that on you ;-), my thinking is to find a process
that works within that constraint, vs trying to work around it. So
naturally I questioned the reason for needing separate areas for each build!
:-)
And to the reference to a build tool, with the phrasing of the needs, I
couldn't tell if your build tool had some requirement to always build to a
new location (e.g. a specially named dir for the build it was beginning) or
it was a de facto process need.
I think others have suggested the probable best approach to work within that
constraint by using a temporary workspace (not what you want to do, but
...!!). You can script the creation of a workspace for this in a build
pre-process script - source controlled and a permanent workspace used for
syncing it (and any other needed files) to the build server.
> -----Original Message-----
> From: Roy Smith [mailto:smith_roy at emc.com]
> Sent: Friday, January 18, 2008 9:11 AM
> To: Jeff Jensen
> Cc: 'Perforce-User at Perforce. Com'
> Subject: Re: [p4] Using current directory as client root?
>
> Well, we're getting somewhat far afield from p4 issues, but yes, it's
> a requirement. Having all the artifacts of the entire build process
> preserved and available for inspection is a part of our process which
> has existed for years and spanned several generations of tools.
>
> It's funny that you talk about process being "inflicted by a built
> tool", because from our point of view, it is perforce that is
> "inflicting" on us the pressure to build in a single fixed directory,
> when none of our previous tools imposed that :-)
>
>
> On Jan 18, 2008, at 9:46 AM, Jeff Jensen wrote:
>
> > Is that a self-imposed requirement or inflicted by a build tool?
> >
> > While following this thread, I have been wondering about your
> > flexibility to
> > question that original requirement, as it seems the "easiest"
> > solution is to
> > not have it! I've been curious as to why a subsequent build of the
> > same
> > codeline can't use the same dir location...
> >
> > Instead, to have scorched earth builds, sync to none (p4 sync
> > #none) and
> > then remove the dir. Then sync to the changelist of choice and
> > proceed.
> >
> > That works great if there is no "need" for the prior build source
> > and target
> > dirs to remain for some reason.
> >
> >
> >> -----Original Message-----
> >> From: perforce-user-bounces at perforce.com [mailto:perforce-user-
> >> bounces at perforce.com] On Behalf Of Roy Smith
> >> Sent: Thursday, January 17, 2008 11:05 PM
> >> To: Slava Imeshev
> >> Cc: Perforce-User at Perforce. Com
> >> Subject: Re: [p4] Using current directory as client root?
> >>
> >> The basic idea we're looking at is for each build run to use a
> >> different working directory.
> >>
> >> On Jan 17, 2008, at 5:13 PM, Slava Imeshev wrote:
> >>
> >>>
> >>> -------------- Original message ----------------------
> >>> From: Roy Smith <smith_roy at emc.com>
> >>>> We're trying to stay away from copying.
> >>>
> >>> That's understandable.
> >>>
> >>> In your requirements, are repeatable build runs expected to use a
> >>> different working
> >>> directory/client root every time?
> >>>
> >>> Or, is every codebase supposed to use a different but stable client
> >>> root for its builds?
> >>>
> >>> Regards,
> >>>
> >>> Slava Imeshev
> >>> www.viewtier.com
> >>>
> >>>
> >>>>
> >>>>
> >>>> On Jan 17, 2008, at 3:59 PM, Slava Imeshev wrote:
> >>>>
> >>>>> Roy,
> >>>>>
> >>>>> Another solution could be having a build system to sync at a
> >>>>> default place and then copy the
> >>>>> workspace to the required on-demand location, passed as a
> >>>>> parameter
> >>>>> to the build system at build
> >>>>> time. Or, have each build a custom client root. Both are pretty
> >>>>> straightforward and don't require
> >>>>> any hacking. Is this something you are looking for?
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Slava Imeshev
> >>>>> www.viewtier.com
> >>>>>
> >>>>>
> >>>>>
> >>>>> --- Dave Lewis <dlewis78731 at gmail.com> wrote:
> >>>>>
> >>>>>> We generally just create a new client for each build. If a
> >>>>>> build was
> >>>>>> certified by qa, you could label it as the release if
> >>>>>> necessary. It
> >>>>>> never occurred to me that there was anything undesirable about
> >>>>>> it.
> >>>>>> Just my point of view. Its interesting to rethink these sorts of
> >>>>>> things when somebody comes along and says they don't like that.
> >>>>>> There
> >>>>>> was the issue of cleaning up the clients at some point
> >>>>>> afterwards. I
> >>>>>> think, though, that this is fairly straightforward usage
> >>>>>> compared to
> >>>>>> various other somewhat crooked approaches.
> >>>>>>
> >>>>>> dave
> >>>>>>
> >>>>>>
> >>>>>> On Jan 16, 2008 9:47 PM, Roy Smith <smith_roy at emc.com> wrote:
> >>>>>>> Yeah, this sounds like mostly what I'm looking for. It's still
> >>>>>>> annoying that you have to create a transient clientspec, though.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Jan 16, 2008, at 7:06 PM, Robert Cowham wrote:
> >>>>>>>
> >>>>>>>> Sounds like that might be addressed by:
> >>>>>>>>
> >>>>>>>> http://www.perforce.com/perforce/doc.072/user/relnotes.txt
> >>>>>>>>
> >>>>>>>> Release 2007.2.
> >>>>>>>>
> >>>>>>>> Major new functionality in 2007.2
> >>>>>>>>
> >>>>>>>> New 'p4 sync' option bypasses db.have updates - #111247 **
> >>>>>>>>
> >>>>>>>> 'p4 sync' now sports a '-p' option. This allows the
> >>>>>>>> user to
> >>>>>>>> sync files without the server keeping track of it.
> >>>>>>>> This
> >>>>>>>> option is very useful when populating build clients
> >>>>>>>> or when
> >>>>>>>> publishing content when there is no requirement for
> >>>>>>>> saving
> >>>>>>>> the client workspace state.
> >>>>>>>> (Bug #22857).
> >>>>>>>>
> >>>>>>>> This would require the "create temporary client hack", but
> >>>>>>>> perhaps
> >>>>>>>> solve the
> >>>>>>>> problem??
> >>>>>>>>
> >>>>>>>> Robert
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: perforce-user-bounces at perforce.com
> >>>>>>>>> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Roy
> >>>>>>>>> Smith
> >>>>>>>>> Sent: 16 January 2008 19:58
> >>>>>>>>> To: Perforce User
> >>>>>>>>> Subject: [p4] Using current directory as client root?
> >>>>>>>>>
> >>>>>>>>> I have a requirement (as part of our build system) to be able
> >>>>>>>>> to get a set of files from the repository and have them
> >>>>>>>>> written to any arbitrary directory. Because the root path is
> >>>>>>>>> embedded in the client spec, there doesn't seem to be any way
> >>>>>>>>> to do this.
> >>>>>>>>>
> >>>>>>>>> We've played with all sorts of hacks. We can create a
> >>>>>>>>> symlink from the root path embedded in the client to where we
> >>>>>>>>> really want the
> >>>>>>>>> files. We can create and destroy temporary client specs on
> >>>>>>>>> the fly.
> >>>>>>>>> But all these seem like hacks. Surely there must be some
> >>>>>>>>> simple way to say, "just put the files HERE".
> >>>>>>>>>
> >>>>>>>>> We don't need the workspace to be managed by perforce. We'll
> >>>>>>>>> never want to edit the files there, or submit any changes
> >>>>>>>>> from there. We just want a read-only copy of the source tree
> >>>>>>>>> so we can build it.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> -------------------
> >>>>>>> Roy Smith <smith_roy at emc.com>
> >>>>>>> Software Guy, EMC Common Management Group
> >>>>>>> 44 South Broadway, 7th floor
> >>>>>>> White Plains, NY 10601
> >>>>>>> (914) 580-3427
> >>>>>>> AIM: roysmith649
> >>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>> perforce-user mailing list - perforce-user at perforce.com
> >>>>>>> http://maillist.perforce.com/mailman/listinfo/perforce-user
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> perforce-user mailing list - perforce-user at perforce.com
> >>>>>> http://maillist.perforce.com/mailman/listinfo/perforce-user
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> -------------------
> >>>> Roy Smith <smith_roy at emc.com>
> >>>> Software Guy, EMC Common Management Group
> >>>> 44 South Broadway, 7th floor
> >>>> White Plains, NY 10601
> >>>> (914) 580-3427
> >>>> AIM: roysmith649
> >>>>
> >>>
> >>> _______________________________________________
> >>> perforce-user mailing list - perforce-user at perforce.com
> >>> http://maillist.perforce.com/mailman/listinfo/perforce-user
> >>>
> >>
> >> -------------------
> >> Roy Smith <smith_roy at emc.com>
> >> Software Guy, EMC Common Management Group
> >> 44 South Broadway, 7th floor
> >> White Plains, NY 10601
> >> (914) 580-3427
> >> AIM: roysmith649
> >> _______________________________________________
> >> perforce-user mailing list - perforce-user at perforce.com
> >> http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >
> >
> >
>
> -------------------
> Roy Smith <smith_roy at emc.com>
> Software Guy, EMC Common Management Group
> 44 South Broadway, 7th floor
> White Plains, NY 10601
> (914) 580-3427
> AIM: roysmith649
>
More information about the perforce-user
mailing list