|
Probably geared more toward enterprise users, but Perforce has a free license for 2 users. There's a great O'Reilly book for Perforce which provides plenty of cookbook-style useful tips and pitfalls. At work we use Perforce not only for source control but also as a transport mechanism between sites (replacing something like Rsync or Robocopy).
|
#
¿
Apr 11, 2009 16:13
|
|
|
|
| # ¿ Apr 28, 2024 05:29 |
|
|
sklnd posted:What's the point of storing builds in source control versus just using the file system? In my work's case, in Operations we gain the benefit of guaranteeing consistency and versioning by using perforce to house and transport our builds. Distributing a build from one site to another is an atomic operation with perforce, either the whole thing submits or it fails. Using a file system + rysnc type of housing/transport, it takes more work to track issues and has less flexibility compared to what perforce could provide out of the box.
|
|
#
¿
Jul 11, 2009 05:29
|
|
|
sklnd posted:Seems like a lot of overhead for what you could achieve with tar, scp, and md5sum. It's more useful for 3rd party and non-technical drops. Instead of providing a list of protocols/procedures to follow its easier to roll up the drop into one user-friendly p4 submit and be done with it.
|
|
#
¿
Jul 13, 2009 08:57
|
|
|
Anyone with experience using Perforce ever done the following? I haven't seen any documentation on built-in support for this. Take a given perforce client (workspace), which is in any unknown "dirty" state -- files missing or added under the root, have list out of sync, etc -- and return it to a known-good "clean" state, which can be defined by an array of perforce labels. It is safe to assume the root of the workspace is unique and does not overlap with other workspaces. I'm curious what CoC may know about this. I've come up with two solutions to solve this, but am I reinventing the wheel? 1) Wipe the entire client root and have list and re-sync to the array of labels. (Very inefficient since labels may contain 10+ Gb in some cases) 2) Wipe the have list, then re-flush have list to array of labels. Then p4 diff under the workspace root for a list of any files not equal to have list revision and force-sync those files. Then remove any files on host under the workspace root not contained in have list. The use case is to guarantee production end points are truly cleaned after this process runs. Rapportus fucked around with this message at 15:29 on Aug 6, 2009 |
|
#
¿
Aug 6, 2009 15:22
|
|
|
lol if you posted:But aside from file syncs and submits what would be generating gigs of file transfers? Are you putting built assets into P4 and using that as a patch distribution system? We put build assets into p4 as a distribution/deployment system, however we took a distributed approach so we're using separate/independent p4 servers in each location. Builds propagate between sites using rsync. With this model, syncs and submits are always done within the same site (fast) and the heavy lifting across WAN is done by rsync (which is more efficient since it often transfers far less than a p4 sync/p4 submit would have to). On an average day we push 150-200 GB of fresh data into each p4 server. Now if only p4 sync could have a delta mechanism like rsync does...
|
|
#
¿
Aug 22, 2011 05:59
|
|