Jump to content

tucny

Members
  • Content Count

    20
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by tucny

  1. In my case, it turned out the certificate was expired. It would be nice if Plastic server reported this somehow, at least in its log file.
  2. Well my issuer is my local custom certification authority (Active Directory CA) which is up and running and its certificate is valid till the year 2108.
  3. Same issue here. Our cert is issued by a local CA (AD CS). So far it worked but stopped now. The CA's cert is valid and published to all machines via AD. OpenSSL show the following validation errors: depth=0 /CN=kara.corp.boldbrick.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=kara.corp.boldbrick.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=kara.corp.boldbrick.com verify error:num=21:unable to verify the first certificate verify return:1
  4. Well, that's a good point. However, numbers as names are far less user-friendly for database maintenance tasks than repository names. Plus, when I rename a repository, it creates a handful of issues with all workspaces around, so one more database maintenance task is of a negligible concern in that situation.
  5. I'm planning a reinstall of our Plastic server on new OS a SQL versions (I know, I know, Jet… but…). What's annoying me is that the databased in SQL Server (have 100+ of them) are named according to some repository number. What I'd like to have are database files "repo_boldbrick-framework.mdf", where "boldbrick-framework" is a sample repository name. All our repos are named according to the "<customer>-<project>" pattern. I read in the documentation about the database creation command. However, there's no variable for the repository name. Can I, somehow, customize database names like above? What can I do about the existing database file names during server migration?
  6. Ah cool! Thanks a lot, I didn't notice the item in the Advanced menu.
  7. I have this scenario: quite an old reference changeset (like 100 revisions back, even a lot more), representing a version used by the customer several branches with new features and fixes, newer that the reference changeset request for a patch release, which would include a few of the fixes and new features Obviously, I'd start a new branch for the patch release from the reference changeset. However, the issue is how to merge the selected fixes and features? Cherry picking individual changesets is not an option — I'd have to do this over like 20–30 changeset. On the other hand, the fixes and features are located in like 3 branches. What I'd like to be able to do, is cherry pick a whole branch, i.e. all changes done in a particular branch. This way, in my situation I'd cherry pick three times instead of thirty. Quite a big difference. From my perspective, the atomic changeset concept, while otherwise logical, is quite failing to support real-world scenarios like this case.
  8. Living in the same repo is fine. However, if I create a top-level branch, I have to create it from some other branch anyway, right? In that case, the new top-level branch for the new version will implicitly inherit all content from the old version. I'd rather prefer picking files into the new version one-by-one. Is this possible? Or do I have to approach it the opposite way and delete files that I won't need in the new version? The reason why I don't like this approach is that a) I can't tell now which files I will need, b) this doesn't match the development workflow, where the new version is going to be developed module after module.
  9. I have a sort of advanced scenario regarding 'continuation of repositories' and I'm looking for a reasonable strategy. I have a repository for a product, version 1, with the latest changeset number, say, 2000. I am going to start development of a new version 2 of the same product. A portion (like 50 %) of the source code from version 1 will be reused and largely refactored. However, version 2 will be primarily a green-field development with a completely new architecture (from the C# source code perspective, different structure of the solution, layering, decomposition into projects, etc.). It makes no sense to start with the existing codebase at changeset 2000, and start changing it from changeset 2001. On the other hand, there is continuity, version 1 will have to be maintained (more changesets to come) and for the the reused portion of code versioning history is desirable. Normally, I'd start a new repository and go from changeset 1. However, that provides no link to the old (but reused) code, no versioning history, and no changeset number continuity. Is there any to solve this in Plastic? Something like Create a top-level branch in the original repository, which would be somehow forced to be empty at first. Start version 2 development there, and then selectively merge the reused files. Not sure if there's a way to create a new top-level but empty branch? Start a new repository and use xlinks to bring in the original code to be reused. Not sure if xlinked content can be modified and become a local copy, having the original xlink for version history only? In case of the new repository, it there an option to force it starting from a given revision number, e.g. 3000?
×
×
  • Create New...