[p4] Usefulness of "file spec" integrations

[Jeff A. Bowles]

In effect, "yeah, what Steve said."
I think that "p4 integrated   pathname/..."  will be your friend, and if
you're a Perl hacker you'll want to know about "p4  -Ztag  integrated
 pathname/..."

The sorta-silly description of a technique...

*So is this roughly some combination of dumping branch history, piping it
through hypothetical sed-type scripts and saving the output as a branch
spec?*

... *is pretty much on the money*.  I'd use Python or Ruby with the marshal
binary (data) formats, for my own tastes, but ... that's about what I'd do.
You pegged it.

    -Jeff Bowles


ps. I'd also write a bit of error-resistant code that notices integrations
that are inconsistent with normal branch usage.

On 9/18/07, Stephen Vance <steve at vance.com> wrote:
>
> File spec integrations are most useful for one-time and simple
> integrations. My rule of thumb is that if I think the integration will
> be used more than once, I use a branch spec. Also, you can only fake
> things like exclusions (i.e. integ and then revert a subset) with the
> file spec approach.
>
> Now that things have stabilized in your environment, is it feasible to
> create a branch spec? As for automating that, you could probably at
> least get an assist from the various commands that take the '-i' option
> to follow branch history. Yes, you could do file-to-file. Whether that
> is advisable depends on the magnitude and regularity of the changes you
> made.
>
> Steve
>
> Brian Topping wrote:
> > Greetings,
> >
> > I'm hoping someone here can explain the relative benefits of file spec
> > versus branch spec integrations.  It's pretty clear what the latter does
> > with the ability to do single-click resolves between two branches, but
> it's
> > less clear how to do the same thing with file spec integrations.  And if
> > they aren't possible, what file spec integrations are good for at all.
> >
> > Here is my scenario:  We have a Java source tree with approximately 20K
> > files that needs major reorganizations to work properly in Ant.  The
> major
> > moves to the source tree were initially made with a branch spec, but
> this
> > proved too unwieldy with thousands of files that needed to be
> moved.  Moving
> > forward, a few dozen file spec integrations were done via an IDE.  The
> new
> > source tree is working, and now we need to resolve changes that were
> made in
> > the original source tree during that time to the new source tree.
> >
> > One or two people on the internets have said that this is possible, but
> the
> > only way I can see to resolve files across a file spec integration is to
> do
> > them one by one.
> >
> > Certainly there must be a way to salvage three months of work that went
> in
> > to creating this new source tree with file spec integrations.  Ideally,
> this
> > would be possible with some black magic command-line incantation that
> > resolves the two branches (regardless of how a particular file was
> > integrated), but in the worst case, maybe there is some kind of report
> that
> > can be dumped for a branch that generates a branch spec
> integration.  (The
> > latter should be possible, all the integration information is in the
> > changelist logs.)
> >
> > Thanks kindly for any information,
> >
> > Brian Topping
> >
> >
> >
> >
> >
> > Brian Topping Platform Engineering
> > btopping <mailto:vmorris at northstar.com> @northstar.com P 415.344.6164 M
> > 415.577.6444 F 415.344.6150
> > 575 Market Street, 14th Floor, San Francisco, CA 94105
> > …………………………………………………………………………………………………………………..
> > NorthStar ● Wealth Management Software Solutions ●
> > <http://www.northstar.com/> www.northstar.com
> >
> >
> > IMPORTANT: The information contained in this e-mail message is
> confidential
> > and is intended only for the named addressee(s). This message may be
> > protected by the attorney/client privilege. If the reader of this
> message is
> > not the intended recipient (or the individual responsible for the
> delivery
> > of this email message to the intended recipient) please be advised that
> any
> > re-use, dissemination, distribution or copying of this e-mail message is
> > prohibited. If you have received this e-mail message in error, please
> reply
> > to the sender that you have received this message in error and then
> delete
> > it. Thank you.
> >
> >
> >
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
>
> --
> Stephen Vance
> www.vance.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com