How to automatically copy files from version control to local path on every reboot

[sturmovik]

Hi Everyone,

In my company, we are on a process to slowly migrate from ClearCase to Plastic SCM. They have devised a lot of methods to work with ClearCase over the years, and I am currently trying to "migrate" a specific procedure from CC to Plastic.

 What we do in CC:

 

1- We have a common view, let's call it common_view. It has its config spec set to retrieve the correct version of some files using a specific label.

2- Every user has a bat file on their startup configuration (we are using windows)

3- This batch file:

• Starts common_view from CC server using cleartool (and maps it to X:\common_view\ )
• Copies (overwrites certain files (mostly perl scripts and batch files) from the CC view to a specific location (in AppData folder of the user)

I would like to do this with plastic. We have already created a repo & workspace with the necessary files and applied the required label to the correct versions of the files.

 

What I need is to download those files to a specific local path (that can be accessed via a script, on all of the users' computers) using a command line interface (I believe cm is the cleartool of Plastic, so to speak). How can I achieve this?

 

Thank you very much for your help in advance.

[calbzam]

Hi,

If I properly understand, you are trying to apply a similar workflow you are currently using with ClearCase into Plastic SCM. Let me show firstyou the following link where we  show some reasons to consider Plastic instead of CC

http://blog.plasticscm.com/2012/05/want-to-switch-from-clearcase-this-is.html

In my opinion, it would make more sense to adapt your previous workflow to get the best experience with Plastic SCM. Instead of trying to replicate exactly the same procedure you are currently using with CC. If you reach us at support@codicesoftware.com, we can arrange a session and discuss the details.

Answering your question:

- In Plastic SCM the basic element is the changeset and a long time ago we switched from a per-file merge tracking to a per-changeset merge tracking.

Key differences between per-file and per-changeset: (http://blog.plasticscm.com/2018/02/why-checkin-asks-to-update-first.html)

Speed: if you merge 1000 files, per-file will need to walk 1000 version trees, one for each file. It doesn't scale. That's why old version control systems normally prevented developers from using too many branches.

Merge all or nothing: with per-changeset when I merge a branch I merge all the files changed on the file... or none, but I can't simply merge a few. This is because the link is set per-changeset, so there's no way to say "hey, only a few were merged, keep the rest for a future merge". With per-file you can do that. When you merge task127 to main you can decide to merge only foo.c, and bar.c will be proposed again to merge if you try to merge the branch again. Flexibility comes at a cost - performance and much higher complexity.

- Following this same philosophy, a Plastic label is applied to a specific changeset (not to a file). So if you update your workspace to a specific label, you will actually download the full content of the labeled changeset. 

- If you still want to follow a file-based workflow, Plastic also has too called Gluon. It comes with Plastic, has no extra cost, and supports a different workflow. It is perfect for working with non-mergeable files (art, docs...).

- In Plastic, every operation can also be achieved via command line "cm". The "cm cat --help" command allows downloading the content of a given revision.

If you want to update your workspace to a specific label, you can run " cm switchtobranch --label=BL050".

Regards,

Carlos.

[sturmovik]

Hi Carlos,

Thank you very much for your assistance. I've been working on this on-and-off due to our varying workload. I've finally set up a solution I'm satisfied with, and I would like to share it for future reference.

We have created a specific repository $repo on our server for those files. $repo has a $branch that only has the "release" versions, meaning any other changes on those files are made on different branches.

I've created a batch file that does the following:

1. Create a temporary $workspace for $repo using cm mkwk
2. Switch to latest changeset of $branch using cm switch
3. Set permissions and copy & overwrite files from $workspace to the requested path
4. Remove $workspace using cm rmwk
5. Delete the $workspace folder

This procedure also has the advantage of automatically applying updates by simply checking-in the updates to $branch.