Jump to content


P4Sven

Member Since 14 Dec 2010
Offline Last Active May 11 2017 10:41 AM
-----

#22836 new user limit makes restore imposible

Posted P4Sven on 08 January 2018 - 11:05 AM

There is an easier way.

Start up the server with the '-n' option, known as the maintenance mode. This will work even if you are above the user license limit.
Delete the extra users (and clients if you are above the limit), then shut down the server, upgrade and restart.

Alternatively, you can always purchase some licenses for support and unlimited clients ...

Cheers,

Sven Erik

--

Sven Erik Knop | Principal Solutions Engineer
Perforce Software<http://www.perforce.com>
T: +44 1189 771020<tel:+441189771020> | M: +44 7974 351514<tel:+447974351514>
Visit us on: Twitter<https://twitter.com/perforce> | LinkedIn<https://www.linkedin...force-software> | Facebook<https://www.facebook.com/Perforce>

New code hosting for Git, SVN, and more.
Try Helix TeamHub free today!<http://info.perforce...signature-link>



On 5 Jan 2018, at 22:15, Sambwise <perforce-user-forum@forums.perforce.com<mailto:perforce-user-forum@forums.perforce.com>> wrote:

Posted on behalf of forum user 'Sambwise'.

If you have a backup of the old binaries and a backup of the db (or a
checkpoint), you can roll back the upgrade and delete users that way (or just
not upgrade and keep the old 20/20 limit).  I don't think it's
possible to download the 20/20 binaries any more from Perforce's FTP site
(although I'm sure someone has them squirreled away somewhere).

Failing that, if you're over the limit on users but not clients, the easy
hack is to delete db.user.

If you're over the limit on clients, it's a little harder because
clients are stored in db.domain along with a bunch of other domain entities that
you don't want to delete (like the ones that are part of
depots).  If you end up stuck there I can walk you through doing
checkpoint surgery to hack out just the clients -- hopefully you're okay
with doing some light Perl scripting.   :)



--
Please click here to see the post in its original format:
http://forums.perfor...store-imposible
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com<mailto:perforce-user@perforce.com>
http://maillist.perf...o/perforce-user

_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user



#21814 Setting writable flag for an entire folder

Posted P4Sven on 12 May 2017 - 11:10 AM

Yes this is valid use case.

I think you are best of using +w for the files in that directory and the type map for any new files you generate in that directory, then use 'p4 reconcile' in that directory to pick up anything changed.

Cheers,

Sven Erik

--

Sven Erik Knop | Principal Solutions Engineer
Perforce Software<http://www.perforce.com>
T: +44 1189 771020<tel:+441189771020> | M: +44 7974 351514<tel:+447974351514>
Visit us on: Twitter<https://twitter.com/perforce> | LinkedIn<https://www.linkedin...force-software> | Facebook<https://www.facebook.com/Perforce>



On 12 May 2017, at 12:05, edwinjomathew <perforce-user-forum@forums.perforce.com<mailto:perforce-user-forum@forums.perforce.com>> wrote:

Posted on behalf of forum user 'edwinjomathew'.



[https://forums.perfo...post&pid=21794]
P4Reg, on 2017/05/11 10:12:32 UTC, said:
  You can set the "Allwrite" option for an entire workspace so that all files sync'd will be writable (P4V->Edit workspace->Advanced tab, check the Allwrite option. I'm not aware of a way to restrict this to just a workspace subfolder

That's little risky for me because reconciling entire workspace will take a
long time and I want to prevent accidental editing. The reason why I want to set
a particular directory is because that directory contains some files which are
generated as part of the build process. Build process won't overwrite the
files if they are not writable.



--
Please click here to see the post in its original format:
http://forums.perfor...n-entire-folder
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com<mailto:perforce-user@perforce.com>
http://maillist.perf...o/perforce-user

_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user



#9420 Hard to copy up when files are often modified

Posted P4Sven on 22 March 2013 - 05:33 PM

Hi Nick,

sorry for joining the discussion so late.

I have introduced streams into many companies, and they all are facing the same problem: merge down/copy up does not work well when the main line is highly contended with changes from many users.

Yes, you can work with semaphores, or tell people to stay away from main until you have copied your changes up, but this will slow down the the development work for everyone.

The trick I found that works best is to make the scope of a child branch smaller. The less data there is to merge the less conflicts there will be, and I do not get held up with merging changes of other users in my parent branch.

Virtual streams and imports can help here to split the data out. I create virtual streams on the mainline to break the project into small self-contained chunks, maybe importing in other chunks I need to reference for compile or test purposes without the need to changing it. Then I create a dev stream from the virtual stream and the merge down line will stay mostly grey, making my life much easier when copying up.

I know this sounds fine in theory but is harder in practice, especially if the code base is highly interconnected. There is going to be a pain barrier to go through to turn the code base into components, but it is worth the effort because once the code base is broken down into smaller chunks, development will be so much faster afterwards.

Let us know if you want to know more about this. We are having several talks about this idea at Merge 2013 in San Francisco, and there is always a friendly Perforce consultant available to help you out as well ... :D

Cheers

Sven Erik