[p4] Writing triggers with p4.net ?
matt.janulewicz at lucasfilm.com
Wed Jul 1 13:52:48 PDT 2009
You can do it in both, but (in my opinion) from Windows it's probably
easier to use VisualStuido to do the magic.
In the past I've had situations where we had solutions with 15-20
projects and a certain common file was needed in each one. Rather than
decide which of the 20 projects to put the 'real' file in, it went in a
common/shared directory and was bought into the solution through the
Solution Items. Then each project could add it as a link. This also
allowed it to work properly using the SCC plugin. If you're using
VisualStudio exclusively, this feels like the easier way to go. And it
will make more sense to Windows developers.
You can also do this, in a way, from within Perforce but it could lead
to complicated workspaces. You can map the same file(s) to two different
local locations. This is a valid view mapping:
The '+' sign tells Perforce to override the, ah, override you get when
you have overlapping definitions. The rub with this is that doing
something like this:
p4 sync //test/dir/file.txt
is ambiguous. Perforce doesn't know which one you want (or both) so it
gives you the second one. This is standard Perforce behavior. To sync
both of these you have to use the more explicit client or local path syntax:
p4 sync //my_workspace/dir1/... //my_workspace/dir2/...
or, if you are set in your workspace's root directory:
p4 sync ./dir1/... ./dir2/...
Now that I think of it, I don't know if doing multiple mappings will
work with the SCC plugin. I know that it implements 'p4 where' a lot to
get reverse-mappings but I don't recall if it works with local paths,
client paths or depot paths when it actually tries to sync.
Hopefully that muddies it all up. :)
Naim Akbar wrote:
> That makes alot of sense. Thanks for the advice.
> About this comment..
> Provide one true source, but let folks map it in multiple times if
> need be. This should be a STOPGAP measure until such time as you (your
> engineers) can re-architect your projects in a more organized way.
> ...How can I map this multiple times. Can this be done in perforce
> or is this a visual studio thing?
> Date: Wed, 1 Jul 2009 11:58:52 -0700
> From: matt.janulewicz at lucasfilm.com
> To: naim_akbar at hotmail.com
> CC: steve at vance.com; jab at pobox.com; perforce-user at perforce.com
> Subject: Re: [p4] Writing triggers with p4.net ?
> Seriously, you need to tell your 'powers that be' that they are wrong,
> wrong, wrong, and you are teetering on the edge of a slippery slope.
> The classic idea behind source control is 'one source', meaning a holy
> grail of code, one copy, a single point of reference. If you have 10
> copies of the 'same' file and want to try to keep them up to date with
> each other, forget it. You say as much in your last message, so you
> need to follow your instincts. You know this will turn out badly!
> How will people know which of the 10 they should change? Say someone
> randomly picks one of the 10 to edit, will your script/trigger be
> smart enough to know what the other nine are? Will it check that
> nobody else has one of those nine checked out? Will it then fail, or
> wait for that other checkin? Then how is *that* checkin propagated?
> What if the trigger fails? If you protect the nine 'other' files and
> tell people which one is the correct one to check out, what's to stop
> them from making an 11th copy and using that?
> Sorry to sound so harsh, but trigger-izing this kind of thing is a
> bad, bad, bad idea (and like I said, I do realize that you know this.)
> I guarantee that this approach will end in failure, frustration and
> general mayhem.
> Something Steve Vance said should be pursued (in my opinion):
> "Are you trying to share code between projects? If so, why don't you
> just map the shared part of the depot into the client specs instead?"
> Provide one true source, but let fo
More information about the perforce-user