Jump to content

psantosl

Members
  • Content Count

    910
  • Joined

  • Last visited

  • Days Won

    22

psantosl last won the day on May 31

psantosl had the most liked content!

Community Reputation

36 Excellent

About psantosl

  • Rank
    CTO - Plastic SCM

Contact Methods

  • Website URL
    https://blog.plasticscm.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. Hi Elite PopCorn, Unfortunately no, we don't have an amend option. But, yes, more and more people is asking for it. In fact, I'd like to track somehow how many are really interested: why don't you vote here? https://plasticscm.uservoice.com/forums/15467-general/suggestions/5221214-amend-commits
  2. psantosl

    sync bug

    Thanks for the kind words. It is extremely encouraging for the entire team that you take a minute to share such kind words. Thanks.
  3. psantosl

    sync bug

    Hey, No, no worries. Underneath Xlinks use GUIDs 😉
  4. psantosl

    sync bug

    Are you using Jet as backend? (I bet you do). If so, it is possible to simply "copy" the repo. That being said: you are better served by GUIDs than changeset ids for embedding the number in the executable. We should rethink the clone to preserve the numbers (no reason not to, initially) but it would be a major redesign. I'm not saying it is not worth (it is, you are right in your points), but I'm not sure we'll be able to deal with it shortly. Would it be possible for you to embed the GUIDs instead of the csetid? This is what we do ourselves:
  5. psantosl

    sync bug

    Hi, Is this second diagram the result of a single replica? Or many? It is not usual to see newer csets having older numbers, but it is not impossible. Now, if you use a single repo, then changeset numbers are relevant. BUT, if you are in a distributed scenario, you should only care about GUIDs. Why? Because it is not possible to preserve the sequence, so we don't even try. Suppose you start with changesets 0, 1, 2. You push to a different repo. Now both have 0,1,2. Now both create a new changeset on each side. It would be 3 on both. When you replicate again, the "3" in one of the sides will be "4" in the other. There is no way to keep the same number. That's why we fallback to GUIDs (which are in fact the real IDs used by replica behind the scenes). We certainly could do a bigger effort to try to preserve the same changeset ids when possible (replica to a clean repo) but our algorithm is not taking that into account for various (non-trivial) reasons. During sync, branches are replicated one by one, with no particular order. It means a newer branch could be pushed first, taking some changeset numbers, and then later an older one is pushed, and it will use newer cset ids. That's why the cset ids while unique, are not very relevant. Thanks, pablo
  6. What if you rename the repo? That's the reason why we used ids instead of names. Renaming a database is an extra step (and extra permission) you need. So, at this point, there is no way to replace ids by names, I'm afraid.
  7. You are right! The check should be in bar.c, not foo.c Hey! Thanks for reading and sharing. Send me an email to pablo@plasticscm.com and I'll send you a printed copy once we finally go for print (still fixing a few bugs). Also, I'm so glad to find you are reading it :P. How much did you like it so far?
  8. There is another option: yes, you can create top level branches: To achieve what you want (although, it is more a naming convention than anything else, since the branch will still start from a given point). But then both projects will live in the same repo (which is not such a big issue anyway). I wouldn't go for Xlinks to achieve what you want. Does it help?
  9. Hi, You should write a blogpost once you figure out the solution 🙂 Coincidentally, I wrote something similar for a customer yesterday. Similar, not exactly the same. You can create an empty branch, then push this empty branch to a second repo. And continue devel from there. You'll be able to access most of the history (not the individual branches, though, since you are not replicating them). And you'd be able to push/pull changes if needed. But, I'm sorry, your desired "changeset 3000" wouldn't be there because cset number would go back to zero. Honestly, cset numbers are not so important these days for many now that GUIDs and SHA are there.
  10. This is totally possible if you create "submodules" or simply repos inside repos. Try creating repo main, then main/subrepo and this will happen by default. That being said: we are recommending all our customers to move away from SQL-xxx into Jet, our ad-hoc highly optimized backend.
  11. Sorry for this, I'll try to get this configured properly.
  12. Hi FpffUVROGDdATCp, Yes, I greatly appreciate when our forum users take the time to show up as real persons, instead of hiding names. We have to prioritize answers, and we normally skip handles with weird names since they tend to be spam. That being said: we never ended implementing binary deltas. It has been in the backlog for a long time but, well, we always have more important things in the list, it seems. So, we still split big files in 4MB chunks and store these separately. What is your actual concern with this? Thanks! pablo
  13. Hi Fpf6fUVROGDdA4TCp, Can you update and use a more real name? 🙂
×
×
  • Create New...