Jump to content

Ensuring version history among selected source files across two codebases

Recommended Posts

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?


Share this post

Link to post
Share on other sites


You should write a blogpost once you figure out the solution 🙂

Coincidentally, I wrote something similar for a customer yesterday. Similar, not exactly the same.



You can create an empty branch, then push this empty branch to a second repo.



And continue devel from there. You'll be able to access most of the history (not the individual branches, though, since you are not replicating them).




And you'd be able to push/pull changes if needed.



But, I'm sorry, your desired "changeset 3000" wouldn't be there because cset number would go back to zero. Honestly, cset numbers are not so important these days for many now that GUIDs and SHA are there.

Share this post

Link to post
Share on other sites

There is another option: yes, you can create top level branches:



To achieve what you want (although, it is more a naming convention than anything else, since the branch will still start from a given point).

But then both projects will live in the same repo (which is not such a big issue anyway).

I wouldn't go for Xlinks to achieve what you want.


Does it help?



Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

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



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

  • Like 1

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...