Pro tip: use “Plastic drive” in big refactors
I’m going to explain how I take advantage of Plastic Drive to help during code refactors.
What is Plastic Drive
In case you don’t know, it is just a way to “mount” the contents of a changeset as a Windows Drive. It is a “readonly” mount, so it is not like a real workspace. But it is useful to browse code using your favorite tools (Visual Studio in my case).
The story
I’ve been in the middle of a big refactor for the last few days. I’m cleaning up some Branch Explorer code while working on the new Plastic network layer (new thinner, more optimal protocol, requires different serialization and forces some of the Branch Explorer code to change).
Then, after tons of changes here and there, I needed to check how a given class member was used before my changes.
Just opening files from history is not enough because you want to do a “find references”.
Finding references in an older version
In order to find how those members were used I found myself doing extensive use of Plastic Drive.
The steps are quite easy: first you “mount” the changeset:
You just have to select the changeset you want, then right click on it and choose “Mount this changeset in Plastic Drive”. After a couple of seconds, a new Windows Explorer window will show up, showing the changeset mounted in the new “drive”. By default, it will start on drive z:
Once mounted, I just went to my Visual Studio solution on the z: drive and opened it up, and from there I just located the class I wanted to check and used “find references”.
And I found out that the code I was looking for was not used as I expected… so I ended up having to make more changes… but that’s another story.
Running unit test from the Plastic Drive
Another useful thing you can do is running unit tests from the drive. In my case I ended up breaking some tests. Many were easy to fix, but there were a bunch that turned out to be harder. So, it is very useful to run them on the original changeset (where they worked) and inspect variables from Visual Studio to figure out what worked differently now.
Again, the Plastic Drive probed to be useful here. Instead of having to setup a different workspace, I just ran the unit tests from the drive.
Alternatives
Well, obviously there are alternatives to Plastic Drive.
First you can simply use “browse changeset” and open files one by one to browse the code. But then useful tools like “find references” are not available. Our goal is to extend our “semantic version control” soon to include this, so you can do “find in references” from a diff, for instance, but it is not yet there. Grepping a cset is also something that would be useful probably.
But, while adding some clever find stuff would be cool, it won’t solve things like running unit tests on an older changeset.
At the end of the day most of the development tools use a “file system interface”, I mean, the IDEs simply open files from disk, so what Plastic Drive does is enable interaction through this “standard” interface. The filesystem is the standard access interface used by the IDEs, editors, build tools… anything. There could be other alternatives like every editor providing some sort of extensible interface to access the files, but nothing as standard as the file system.
The obvious alternative is creating a second workspace. As simple as that. You populate your second workspace and then you can “find in files”, run unit tests or whatever you need.
The advantages of Plastic Drive against a second workspace are:
- Plastic Drive is populated on demand. Instead of “downloading everything”, it simply downloads the files really accessed by the tools. In my case, while my full workspace takes about 10GB, building the Visual Studio solution I was working on requires less than 80 MB. So Plastic Drive saves quite a lot of time and disk space…
- Sometimes you feel “lazy” about creating a second temporary thing. You have to download a lot of stuff, then just delete it afterwards. Slow, disk consuming… Ouch! That’s why I love the Drive.
Performance considerations
If you open a Visual Studio solution on Plastic Drive for the first time, and depending on how big it is, you’ll notice it takes a while to load. This is because VStudio reads *all files* on the project, and even tries to compile to be able to enable navigation and so on. So, despite of the fact that Plastic Drive only access files “on demand”, VStudio will be accessing *all files* in the project.
Does it invalidate the Plastic Drive concept? Actually not. I mean, often your VStudio solution will be much smaller than a full tree on the repository. Documentation, images, installer utilities, tools… they can sum quite an amount of megs and they’re probably not required to build the solution you’re after… This is what happens in my case, as I described above.
Second: Plastic Drive creates a local cache with the downloaded files. It means the second time you load the project; it will be way much faster because the files will be already cached on disk. If you mount a different cset on the same repo, the load will be fast too since most of the files will be already there.
And of course I’m talking about VStudio. If you simply browse the drive, only the files you actually open up will be downloaded.
Conclusion
I just wanted to share what I consider a “pro tip” for Windows users: use the Plastic Drive to browse your project using the standard toolset or even run unit tests.
The Drive is not yet available for Linux and Mac, although we’ll try to come up with something similar based on FUSE (Linux) or its Mac counterpart.
0 comentarios: