Jump to content

psantosl

Members
  • Content count

    859
  • Joined

  • Last visited

  • Days Won

    19

psantosl last won the day on April 20

psantosl had the most liked content!

Community Reputation

33 Excellent

About psantosl

  • Rank
    CTO - Plastic SCM

Contact Methods

  • Website URL
    http://codicesoftware.blogspot.com

Profile Information

  • Gender
    Male
  • Interests
    plastic plastic plastic...

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. psantosl

    Plastic Drive filecache

    Hey Jake, Yes, you are perfectly fine to remove the cache. What it does is save locally the contents of files, so the second time you mount your repo (a cset or whatever) it doesn't have to download from the server and it goes much faster. But, if you have been using it for a while, it can be caching tons of things you don't use anymore. We should implement some sort of auto-cleanup :-S Now, question for you: can you share how you are using it? Why do you find it useful, etc. Would be really valuable. Thanks, pablo
  2. The only thing that I'd point is that keeping things simple normally helps a lot. So even if you can reach 10-level nesting, I strongly doubt it is really worth. Remember we provide FREE 1-h sessions with product experts just in case you need to go through some details 🙂 https://www.plasticscm.com/download/freetraining/
  3. psantosl

    Double Branching (Branch Explorer)

    I'll try to reach you to have a conf call about this and learn from your experience!
  4. psantosl

    Double Branching (Branch Explorer)

    Hi, Ok, branches track their head changeset, so they always know which one is the last on the branch. When you create an empty branch, its "head" points to the point where the branch is created from. So, on a regular branch, if you say "create child branch", it is created from the head. If you say "create from this changeset", then the "head" of the new branch points to this cset. It is a special situation because branches only contain changesets created inside the branch, but just during creation, when they are empty, their head points to a cset on a different branch. Now, you have an empty branch (doesn't contain any changeset) and you say: create branch from here. Well, it takes the head of the parent branch, but this head is on a different branch, because there is no changeset in there. So, it is not a bug, it is simply designed to work this way. I understand that, for topology reasons, it could be good to achieve what you want, but this is not what we really support, because branching is not meant to draw better graphics but to allow better workflows. What I mean? I mean that we strongly encourage to keep branch hierarchies as flat as possible, in fact, I have a pending blogpost to explain (both inside and outside) that: * Never merge between task branches unless you can't really avoid it => keep branches independent, it is better for CI flows. * Don't create child branches of task branches if you can avoid it => and normally it means *almost always*. * Keep your branch structure as flat as possible => we strive for trunk based development with task branches, so we try to avoid intermediate release/devel branches if possible. It greatly simplify things while still taking advantage of the super great task branches pablo
  5. psantosl

    CM CI force

    You mean skipping the merge???
  6. psantosl

    The item --- already exists

    Hey, Plastic can detect moves quite well but... it can't do magic, I mean it is based on some heuristics so if you moved TOO MUCH, maybe it is not able to pair the moves anymore. We have a feature to overcome this, which is a little bit experimental, but that could be perfect in your case (if you are in Windows): the Change Tracker Service: https://www.plasticscm.com/download/releasenotes/6.0.16.1151?term=change tracker service An awesome new feature: Plastic Change Tracker service for Windows to precisely track file moves and renames beyond heuristic guessing. It is in experimental mode at this point. This new service takes advantage of the file system internals to precisely track file renames and moves, something we could only guess before (quite well, but just an heuristic after all). It means binary file renames and moves (where diffing does not apply) will be incredibly precise now. How to use it: * You need to install the new service: plasticchangetrackerservice.exe --installservice. Then you can start it with --start or simply going to the service control panel. * Use plasticchangetrackerservice.log.conf to configure log if needed. * Enable it in your client.conf creating a new XML entry named: UseChangeTrackerService, set it to YES. * Restart your client. * Changes will only be precisely tracked while your client is open. You can do the changes directly in Explorer, but you need the Plastic client to be opened. We plan to improve this later. * How do you see it is working? Well, every move won't be "moved locally" but just "moved" now because the change is applied immediately. Enjoy!
  7. psantosl

    The item --- already exists

    Hi, Any chances this directory is detected as new locally but it is indeed already in the server?? Are you on Gluon or regular Plastic? Thanks, pablo
  8. Hi, We recently released a few changes on the locking strategy, and yours sounds quite related. Can you double check you are on the latest release? (or very close to) Thanks, pablo
  9. psantosl

    GitSync and trial license

    Hi Travis, GUI support is Windows-only at this point, since most Linux users are hard-core CLI-only folks. You must use cm sync instead, I'm afraid :-S pablo
  10. Hi Travis, Short answer: you are good with Jet. It is the fastest. Long answer: * For years we developed SQL-based backends. We developed a SQL Server layer, MySQL, SQL Server CE, Firebird, Firebird Embedded (was the default for years), SQLite (quite good performance in almost every scenario except heavy load), even Postgres (never optimized it) and Oracle (the connector we used was super bad and we ended up removing support for it, although the code is still there). Why we did this? Well, when we started coding Plastic back in 2005 we didn't think like reinventing the wheel. We were busy enough coding merge algorithms, GUIs, merge tools, diff tools and so on. And working on storage too was like too much. We performed tests, tweaked things here and there, and decided a stable database layer was going to be the way to go, building on top of rock solid software. Also, it was hard enough to convince companies they could trust a new version control player, so telling them their data was safe on a standard SQL storage seemed like a good idea. * We never stopped optimizing database code. Things like bulk inserts in SQL Server, the equivalent on SQLite, better use of transactions, grouping inserts, temporary tables when doing many lookups... you know, everything we knew how to do or we learned in the way, we applied it. * Years later we denormalized some data in the database. We stopped storing "trees" (directory structures) in tables as such but as blobs, like regular data. Doing 100k inserts to do a checkin of 100k files wasn't fast enough. Blobs were much better. * Plastic was super fast already and we were able to consistently beat most version control competitors, specially under heavy load. * But at one point we started thinking: hey, how long does it take to save 500k revisions to disk? Nothing. If you serialize the data correctly it takes nothing. And it was nothing compared to several seconds in a database. And what about reading? If we read using "pointers" (we do C#, but we use pointer-based code for this) we achieved super fast speeds. I mean, nothing new under the sun, of course reading/writing to disk is faster than doing the same on a database. But the database is reliable, rock solid, transaction aware, generic for all kinds of data... * Finally some of our biggest customers in games had huge repos with 5-8TB in size, hosted in MySQL, and it started to say "enough". Some small issues here and there in MySQL, random slow downs. * So we said: ok, we have been around for 11+ years, we covered the basics, we developed a bunch of tools, it is not 2005 anymore, we are not starting... let's go for our own ad-hoc storage. And we did it. And those 5-8TB repos were now handled like nothing. Literally nothing. * Then we started moving all our major customers to Jet. Some of them have +1000 users on Plastic/Jet. They are much happier than when they used SQL Server. Easier admin, much faster performance, much faster backups. * So we decided to make Jet the default. So, did we discontinue SQL-based backends? No. We'll we do it in the future? Likely. Reducing the code base is always good, and focusing our performance efforts on Jet is better than trying to make 7 different database backends faster. Ok, hope I answered your question 😉 pablo
  11. psantosl

    making sure artists checkout files

    Hi! Yes, you can configure plastic to set all files as readonly on your working copy (they can always override that, but it helps). How: Or: configure writable.conf or readonly.conf: https://www.plasticscm.com/documentation/gui/plastic-scm-version-control-gui-guide.shtml#TheOtherOptionsTab pablo
  12. psantosl

    checkout/locking in cloud not working

    Hi, You can download (update in Plastic terms, checkout in git terms) your repo in as many workspaces as you want. What do you mean by seeing the checkout on a different machine?
  13. psantosl

    Visual Studio Team Services integration

    We don't have support for GitServer on Cloud yet, I'm afraid. What do you exactly need? Issue trackers? What?
  14. psantosl

    How to verify workspace integrity?

    Hi, There is an update option to force checking hashes. Plastic trusts the modification bit as a way to know the file wasn't changed. Otherwise update would be super slow (if it had to hash everything all the time). So, in the event someone played with the timestamps manually, he could break the workspace. By default Plastic doesn't set repo timestamps on disk, but time when they were downloaded. This is because build systems expect it this way. To force the update, you can try: cm update . --forced pablo
  15. psantosl

    Server Errors Log ERROR Channel

    We'll double check, but it can be simply a log issue, I believe.
×