[p4] Writing triggers with p4.net ?

[Matt Janulewicz]

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:

    //test/dir/file.txt  //my_workspace/dir1/file.txt
    +//test/dir/file.txt  //my_workspace/dir2/file.txt

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.  :)


-Matt


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