0

I'm following the process: Check Out project file and Check In changes through СhangeList. I have a few questions:

  1. Where can I customize code of ChangeList? By default, the code is 1050, 1051, ... - can I change this template?
  2. Can I customize version name in Repository Model Properties? By default name is "1 ** ..**", "2 ** .. **", I need "1.1", "1.2". I only found the edit in the Сomment, but I need to display this name in Repository Model Properties.
  3. Can I add Comment on both the Project file and the Model file separately when Check In into the ChangeList? I can add Comment only to Project file.
Anastasia Lobanova
  • 13
  • 2
  • I don't think you can change the changelist "name". – pascal Jun 16 '21 at 12:16
  • Where do you want to use this version number? In a report, or else? You can add a computed extended attribute, which concatenate a release number, stored on the model, with the repository number. Besides the repository version number does not "exist", outside of the repository. So if you move a model from one repository to another, its repository version will start back to 1. – pascal Jun 16 '21 at 12:18
  • The Check-in comment applies to the top object, be it a Project, Model (or Target, or Extension, or Word file...). For another consideration, the Project Model is "thought" as being part of the project, so for example its references to other models of the same project, will be stored using the Project current path (? PRJ_ROOT_DIR), which would not make sense if the same model was outside of a project... – pascal Jun 16 '21 at 12:21
  • @pascal I want to use a version number, for example 1.3, to send to the release. When I integrate changes into a Project file, I get major versions 1, 2, 3 - can I somehow add the minor suffix .1, .2 to them? – Anastasia Lobanova Jun 16 '21 at 12:36
  • My first feeling is that the repository versions have no existence outside of one repository. No one can use it to check the creation date of the artefact. Also I still stand by my comment, that you can get the same version(s) if you move your model elsewhere... I would have two parts: a logical version, which is managed by hand; and a technical indication, which could be the last checkin (or the extraction date). The first you store in the model comment, or as an extended attribute. The second can be a computed extended attribute, to get whole version numbers like 1.3.20210703... – pascal Jul 03 '21 at 07:48

0 Answers0