Jump to content

Xorcist

Members
  • Content Count

    116
  • Joined

  • Last visited

  • Days Won

    1

Xorcist last won the day on January 29 2013

Xorcist had the most liked content!

Community Reputation

4 Neutral

About Xorcist

  • Rank
    Advanced Member

Recent Profile Visitors

3,841 profile views
  1. So I guess my only "free" option at this point would be to setup cloud edition on both machines and store my code in three places (one of which being offsite and limited to 5GB). I assume I could purchase a single Enterprise License for $262 a year (and upgrade my existing servers) to continue to work offline (within my own LAN), and of course I could interface that with a free cloud account if I wanted to have offsite repositories.
  2. Will the new Cloud Edition affect existing free Personal Licenses (which basically use the Team Edition with a single user license)? How long will the Team Edition be supported for? I have my personal license setup on my laptop as well as desktop and regularly sync changes between them for redundancy and to debug my game builds in both environments. Will the Cloud Edition allow me to work completely offline in the same capacity, or will everything need to sync through the cloud server?
  3. Is there a roadmap to version 9? Just wondering how soon it might be ready.
  4. So I did some confirmation testing, and it looks like it will fire multiple times... I might be able to write a script to fire a gitsync after one or more replicationwrites are detected on the repo (which I would extract from the PLASTIC_BRANCH environment variable), but only after a period of inactivity. Which would hopefully be enough to indicate that the complete sync is finished. What are the chances we could get a new triggers for before-sync and after-sync added into Plastic SCM? Is this a feasible trigger?
  5. So is there no way to trigger after a sync is complete? Won't the after-replicationwrite trigger go off on every replicated branch no matter the repo being replicated (possibly firing multiple times)? I was really hoping to limit the gitsync to only firing after a sync is complete on a specific repo.
  6. I've been reading up on Triggers but I'm not sure I'll be able to achieve my goal. What I would like to do is, after a sync operation completes (on the destination server), for a single repo (not all the repos), I would like that server to then perform a subsequent GitSync from that repo into Azure DevOps. Does anyone know how to set this up, or if it is even feasible.
  7. Does Plastic provide a means for easily generating a change log file from comments? If not does anyone know of a third party tool that might be able to assist in doing this?
  8. * Don't create child branches of task branches if you can avoid it => and normally it means *almost always*. That one is a little tough for us since we rely heavily on a sub task model. For instance we have branches for stories (which in JIRA are tasks with sub-tasks). So we see started to see this odd diagram a lot, and I've just been telling the lead devs to change something, like the proposed version number for the assembly, and check-in immediately on these parent branches before assigning sub-tasks to the junior devs. Just so the tree looks cleaner.
  9. I find this a bit confusing. If I branch to start a new task, then immediately branch again (without changes or a check in of the code) to experimentally test some code, the diagram description is not based on the branches but rather the change-sets, resulting in a semi-confusing diagram (see attachment). Both the original branch, and the subsequent child branch both point to the original change-set. The only way to get the picture I would expect, is to branch, add a dummy change, check it in, then branch off the newly created change-set (which just seems wrong). Is this a bug? You can clearly
  10. I'm not a Linux guru by any measure. I'm comfortable from an advanced user standpoint, but I'm not near the level to answer my own question. So... I followed the wrong instructions (Debian) when installing Plastic on my Ubuntu machine. Everything appears to work, but I was wondering what the process was for removing Plastic and re-installing it properly (and if the Debian release was actually any different than the Ubuntu release, dependencies etc.). For instance, would it be safe to sudo apt-get purge plasticscm-complete or should I just use sudo apt-get uninstall plasticscm-complet
  11. Yes this is for the Windows version of Plastic SCM, and it does appear I am missing that registry key, so I exported the key from another machine (same setup), as well as two missing files (uninstall.dat and uninstall.exe), and re-ran the new installer. This is not the first time the uninstall portion of the install has gone missing. I think it might be related to our virus software, but not 100% sure. At least I got it all working. Thanks for the tip.
  12. is this to be expected? I assumed this install would upgrade me in-place. Should I be uninstalling 6.0.16.1746 first, but keeping my configuration files, like db.conf, etc.
  13. Well I'm actually more interested remote client issues, since they currently have no way at all to check the version of the server they are connecting to. This is important when running into issues with syncs, tube connections, etc. It would be nice if there easy way to get the server version from the Plastic Client GUI and or the CM CommandLine.
  14. Correct me if I am wrong, but it appears that there is no way to get version information about the server from either the Plastic Client GUI nor the CM CommandLine. If fact it appears even accessing the web admin for the server doesn't display any version information about the server itself?!?!! I finally found this information by inspecting the executable on the server (which I luckily had access to and found to be v6.0.16.1765), but that seems a bit extreme just to get the version number. If there is no way do get this information from the client, can we please get that in as
  15. Just started to review Plastic 7.0 and while most of it is all great, I find the new branch explorer to be less appealing, visually, than the old one. Just way too many circles... I mean a head changeset with a label is like four circles (or five depending on how you look at it), just seems overly cluttered. I'm assuming this not a selectable theme and there is no way to go back to the original visualization. Too bad too, as I really liked the more pill shaped changesets of the original.
×
×
  • Create New...