Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


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,355 profile views
  1. Xorcist

    Double Branching (Branch Explorer)

    * 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.
  2. Xorcist

    Double Branching (Branch Explorer)

    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 see the branch names are correct, it's just the lines that seem wrong.
  3. 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-complete? I'm mostly worried about dependencies, etc. My core goal here would be to blow Plastic away completely and start for scratch, pointing to the correct package repos this time obviously.
  4. 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.
  5. is this to be expected? I assumed this install would upgrade me in-place. Should I be uninstalling first, but keeping my configuration files, like db.conf, etc.
  6. Xorcist

    Version Identification (Server)

    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.
  7. Xorcist

    Version Identification (Server)

    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 a feature request. Seems like an important piece of information when debugging issues between clients and servers.
  8. 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.
  9. Xorcist

    Update db.conf (locked)?

    I ended up duplicating the file, and saving it elsewhere, then renaming the existing db.conf and copying my modified file back into the application package. Which appears to have worked.
  10. I'm not exactly a Mac expert here, but I tried to update: /Applications/PlasticSCMServer.app/Contents/MonoBundle/db.conf to include: <CommentLimit>65536</CommentLimit> as our comments also act as our change log in merged nodes to main. But the file is locked, and even unlocking it and allowing everyone to read/write, I still can't edit it. Can someone help me out here?
  11. Xorcist

    Code Review Confusion

    We currently use plastic in a distributed setup with local servers (pulling/pushing from each other), with a master server to manage continuous integration. We wanted to try and use the code review feature of plastic, thinking it worked similar to a pull request in git, but this does not seem to be the case. If a developer has completed his work, and creates a code review for it. I have no idea the work is done because that review does not show up in my plastic client. Can someone explain how code reviews can or should be used in a distributed environment. Right now, when a dev is done, he/she just contacts me and says can you go pull branch whatever, and review it for me. Which is not optimal for management or tracking.
  12. Xorcist

    Add Replication Source (without previous pull)?

    Actually our company already uses Tube. But yes, I want to be able to add any remote server/repo as a replication source in the branch explorer so I can track multiple developers working on a project via "view remote data", but without the need of actually having to have pulled from them first. In fact in my current situation, I have some developers who are on Tube, but they got the original code from our master server (so they did not pull directly from me), and I want to see all their branches as they relate to my current repo, but remotely (I don't want to pull them down into my repo). Is this something I should add a feature request for?
  13. Is there any way to easily add a replication source to a repository without actually pulling a remote branch first? I have several developers that have pulled their repos from the master server, and I want to be able to see their remote data, but they are not in my replication sources list. I have to actually pull a branch first to get them in there... but I don't want their branch, I just want to see the branch to decide if I even want to be pulling it.
  14. My recommendation would be to either to do away with the platform versioning in the URLs, or if that is not a possibility, simply create additional URLs for the appropriate platform versions and just keep the same code-base. Currently the installation instructions are a bit confusing (since a 16.04 repository doesn't exist, though I am told to append my Ubuntu version number), so maybe this just needs to be updated to clarify that 14.04 is the repo to use for Ubuntu 14.04 or higher (and that full compatibility testing has been performed). That would at least be something I could show system admins to ease any worries. If none of that is possible, I could always try to push the ZIP file installs through, thought that is obviously a bit more work all around.
  15. I haven't encountered any issues myself. What I mean by red flags are, other system admins asking why a custom unauthenticated repository specified for Ubuntu 14.04 is being added to the Ubuntu 16.04 package manager on not only our developer machines (which I am in control of), but also one or more servers (which they are in control of). It's just people's perceptions. There may be zero compatibility issues, but someone is inevitably going to ask me about this.