Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 05/26/2019 in all areas

  1. 1 point
    You can use the --cset option to get the output in the original cs:X@repository@server format: c:\mcga>cm status --cset cs:8@rep:test@repserver:localhost:8084
  2. 1 point
    Yes, it is doable 🙂
  3. 1 point
    Hi @tucny, You can create a top-level branch from any changeset using the command line (I don't think you can specify the changeset in the GUI though). This means you could create a new top-level branch from changeset 0, and it would be empty. See this forum post: Obviously being in the same repo means making changes to V2 will increment changeset numbers for V1 (not sure if you care about that). Alternatively, you could do a hybrid approach of what Pablo suggested. Replicate the entire V1 repo into a separate V2 repo. Then use the above approach to create the top-level branch from changeset 0 (inside the new V2 repo, keeping the V1 repo unchanged). Kind regards David PS: I personally label all changesets on main (eg, label M-1, M-2, M-3 etc), which you can automate with triggers. I find this easier than referencing cs:id numbers, which aren't visible in branch explorer and which can also differ across replicated servers when working distributed (meaning you have to refer to them by GUID, which is not easy to read or type). Main downside is it makes things look a bit busier, and if you use labels for releases then those no longer stand out as much (unless the Plastic team also introduce the ability to colour code labels and/or changesets by attribute or custom filter rules *wink wink nudge nudge* @psantosl).
  4. 1 point
    Nice. I never had an occasion to create a subrepo, that makes sense. Thanks! Regarding Jet...it sounds great for speed but I like the transparency and accessibility of SQL Server (being able to use TSQL). I've had minor issues in the past (regarding dangling workspaces when clients were removed without removing their workspaces) where directly modifying the data for a workspace in the SQL table fixed the problem (this was a few years ago). Not having the ability to query/modify Jet data could be an issue. At least with SQL I know that I have an extra layer of visibility into the underling storage system so that if anything goes wrong (corruption for example) and I don't have a recent enough backup for some reason (or a backup wouldn't help, like in my above problem) then I still can potentially fix the issue. The completely closed nature of Jet keeps me relying on my trusted SQL server. Do you have Jet tools (even command line would be fine) that allow for query/update capability if needed? Or do you publish the Jet structure/standard anywhere?
×
×
  • Create New...