Comments on: Sharing code with p4share http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/ Mon, 16 Aug 2010 17:08:37 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Philip Bloom http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-509 Philip Bloom Wed, 19 Aug 2009 21:18:46 +0000 http://toolssig.wordpress.com/?p=303#comment-509 Interesting. We used P4 Proxy for the same problem, having proxies at montreal (3 time zones difference) and the Netherlands (8 I think). While we definitely faced the issue of unscheduled downtime causing trouble, it never actually happened. The only real issue that ever occurred was political rather than technical (Studio X wanting things different than Studio Y using the same proxied server). It ended up being a very cheap and effective solution over the course of the projects that were using them. Interesting. We used P4 Proxy for the same problem, having proxies at montreal (3 time zones difference) and the Netherlands (8 I think). While we definitely faced the issue of unscheduled downtime causing trouble, it never actually happened. The only real issue that ever occurred was political rather than technical (Studio X wanting things different than Studio Y using the same proxied server). It ended up being a very cheap and effective solution over the course of the projects that were using them.

]]> By: Geoff Evans http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-508 Geoff Evans Tue, 28 Jul 2009 15:46:12 +0000 http://toolssig.wordpress.com/?p=303#comment-508 Since we are on different coasts and separated by 3 time zones we wanted different downtime windows for each office, and we also wanted complete independence to prevent unscheduled downtime in Burbank from stopping production in Durham. Since we are on different coasts and separated by 3 time zones we wanted different downtime windows for each office, and we also wanted complete independence to prevent unscheduled downtime in Burbank from stopping production in Durham.

]]> By: Yacine Salmi http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-507 Yacine Salmi Tue, 28 Jul 2009 13:34:44 +0000 http://toolssig.wordpress.com/?p=303#comment-507 Hi Geoff, An interesting solution. I'm assuming you came across the Perforce Proxy system (http://www.perforce.com/perforce/doc.091/manuals/p4sag/09_p4p.html) before deciding to write your own solution. Why did you choose to go with p4share instead of using Perforce's solution? Hi Geoff,

An interesting solution. I’m assuming you came across the Perforce Proxy system (http://www.perforce.com/perforce/doc.091/manuals/p4sag/09_p4p.html) before deciding to write your own solution.

Why did you choose to go with p4share instead of using Perforce’s solution?

]]> By: Geoff Evans http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-506 Geoff Evans Mon, 27 Jul 2009 15:41:38 +0000 http://toolssig.wordpress.com/?p=303#comment-506 That definitely works, but you need two more branches and two more integrates to get it done. Sorry, I didn't mean to imply that my way is the only way :) That definitely works, but you need two more branches and two more integrates to get it done.

Sorry, I didn’t mean to imply that my way is the only way :)

]]> By: Tom Hill http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-505 Tom Hill Mon, 27 Jul 2009 09:39:32 +0000 http://toolssig.wordpress.com/?p=303#comment-505 My ASCII art seems to be formatted a little wrong, here's another try: Studio.A.Server......................................Studio.B.Server ------------------------.............................------------------------ Studio.A.Production.Code.............................Studio.B.Production.Code ....../\................................................../\ ......¦....................................................¦ ......¦....................................................¦ ......\/..................................................\/ Studio.A.Mirror.Drop.Branch...Studio.B.Mirror.Drop.Branch My ASCII art seems to be formatted a little wrong, here’s another try:

Studio.A.Server………………………………..Studio.B.Server
————————………………………..————————
Studio.A.Production.Code………………………..Studio.B.Production.Code
……/\…………………………………………../\
……¦…………………………………………….¦
……¦…………………………………………….¦
……\/…………………………………………..\/
Studio.A.Mirror.Drop.Branch…Studio.B.Mirror.Drop.Branch

]]> By: Tom Hill http://thetoolsmiths.org/2009/07/26/sharing-code-with-p4share/comment-page-1/#comment-504 Tom Hill Mon, 27 Jul 2009 09:33:41 +0000 http://toolssig.wordpress.com/?p=303#comment-504 I'm not sure whether I'm reading your post correctly, but it sounds to me that you describe a situation that a depot 'mirroring' technique might be more applicable? The basic idea is that you have a 'mirror' branch in both Studio A and B's depots. In Studio A, when you want to create a code drop, you branch that drop into the second branch (Adrop). Then you take these changes and apply them directly into a mirror branch in B's depot (Bdrop). Next you branch the changes from Bdrop into Studio B's normal development branch. In this way you can take full advantage of Perforce's integration tools - maintaining history along the way, and the best bit is that the whole process works two ways. Studio B can send changes back to Studio A with exactly the same process but in reverse. Studio A Server Studio B Server ------------------------ ------------------------ Studio A Production Code Studio B Production Code /\ /\ ¦ ¦ ¦ ¦ \/ \/ Studio A Mirror Drop Branch Studio B Mirror Drop Branch Would there be any difficulties in you using this approach? I’m not sure whether I’m reading your post correctly, but it sounds to me that you describe a situation that a depot ‘mirroring’ technique might be more applicable?

The basic idea is that you have a ‘mirror’ branch in both Studio A and B’s depots. In Studio A, when you want to create a code drop, you branch that drop into the second branch (Adrop). Then you take these changes and apply them directly into a mirror branch in B’s depot (Bdrop). Next you branch the changes from Bdrop into Studio B’s normal development branch. In this way you can take full advantage of Perforce’s integration tools – maintaining history along the way, and the best bit is that the whole process works two ways. Studio B can send changes back to Studio A with exactly the same process but in reverse.

Studio A Server Studio B Server
———————— ————————
Studio A Production Code Studio B Production Code
/\ /\
¦ ¦
¦ ¦
\/ \/
Studio A Mirror Drop Branch Studio B Mirror Drop Branch

Would there be any difficulties in you using this approach?

]]>