Suggestions

[Pontiac]

I'm coming from a SCM called Team Coherence (TC). Its an absolutely fantastic product, however, its been more than a year since its last update, so chances are the developer(s) have just given up on it. Time to move on.

Right now, I'm learning the ropes with P.SCM and have a few feature suggestions that TC has that P.SCM doesn't, and some things I've wished TC could do. Some of what I'm about to suggest MAY be in the this application already, so, don't flame me too bad. I've really only put this app to the burner for a few hours so far today. I've BRIEFLY gone over the help documentation, but, towards the end of my shift, I start going cross-eyed reading walls of text.

Things TC has that P.SCM doesn't:

1> TC has the built in ability to treat multiple item types as one item. For example, forms in Delphi are defined by one file, while the code to operate the form is written in another. The form is a DFM file, and the source code is a PAS file. The TC client visually merges these two file types as one item in the client, so when I do one check-out, both files get checked out at the same time. The Delphi project definition file has 4 files including the RES, DPR, CFG, and DOF. When checking out the DPR file, the RES, CFG and DOF file gets the same treatment automagically and are checked out at once. Having the option to customize what files should be grouped together, and what the primary file for this group should be would be tremendous and saves guess work in later projects. For instance, I could group Sqlite3.dll and coresponding unit wrappers together, share them (See next note) and source code and DLLs are up to date across all my projects. Flexibility is key, right?

2> TC has the ability to share files across projects and directories. Take for instance the SQLite3.dll again. You could have several projects that rely on this particular DLL. When you update this DLL in one project, TC updates one entry in its database, and the project you're currently actively working on is up to date. However, when you go to any other project that also shares SQLIte3.dll, the TC client will report that this file is out of date, and it'd be up to me to test the revision out. The perk here is that if I have a wrapper for SQLite3.dll that needs updating to reflect the changes in the DLL, I modify the wrapper in one place and check in the changes. Any other project down the road that I check-out will have the new changes, so I never have to remember to update the wrapper for the new DLL.

3> I've put my three votes on it, but, I'll add it here anyways... Having the ability to toggle seeing files that are intentionally being ignored Plastic would be awesome. When you set something to be ignored in TC, you don't see it. Its not managed, never checked in, always set with whatever file attributes it had when it was created. TC treats these files like the mother-in-law you never wanted, and completely avoids any interaction with them (My mother-in-law is pretty cool, just for the record). With P.SCM, I'm LOVING the fact that you can ignore files globally or on a per-project basis with just a few mouse clicks, and, then later on, permit files to be maintained in edge cases with a few mouse clicks. With TC, the functionality is there, but you have to go digging in the properties for the project and do some actual typing. Score for P.SCM.

Things that neither TC or P.SCM has, that I think should.

I code in two places. At home, and at work. At home, I'll be on one of three machines. Two physical, and one virtual I may RDP into. I run TC services at home, so when at the office, I connect home via VPN. *MY* behaviour is when I'm coding, my SCM client is kicking around in the background so I can do quick check ins, or check outs, or revert code or whatever I need to do. I DON'T use the IDE integration as the VPN can get flakey, and sometimes locks up the entire IDE, not to mention that even though the IDE integration of TC into Delphi is impressive, its more intuitive and more visually accurate looking at the TC client, not to mention if I need to modify the state of a file not managed by the IDE, I have to go to the client anyways. Unfortunately, at the end of a long shift at the office, I tend to sometimes forget to upload my changes to TC, or I do the check in but COMPLETELY brain-fart on the fact that I've made 3 new units that should be included in the project. From what I've seen, P.SCM saves me on the missing file when I go to check in, but, it doesn't save me when I just close the application to go home. So when I go do my coding over the weekend at home, my code isn't in the SCM, which means, first off, that my code is at risk, and second, I have to run back to the office and do the check in so I can keep working at it at home. Unfortunately this can't happen all the time since the machine in the office is a shared machine and the drive my data is on is physically turned off on that machine.

What I'd LIKE to see is that when the client is instructed to shut down, it scans all monitored directories for any changes to files, or any new files created, and alerts the user PRIOR to actually shutting down.

Now, before you P.SCM developers get on my case and start hounding me that scanning ALL directories at shut down is a bad idea, and can take FOREVER to check for file state changes, ESPECIALLY over a WAN to get to the server, you're "abso-freak'n-lootly" right.... ... that is if you check EVERY directory every time you shut down the client. Almost 100% of the time you'll never BE in every directory in larger projects, and if the project is large enough, you won't even be in 1% of the directories the SCM is managing. So part of the puzzle here is to have the P.SCM client periodically check to see if a new file has been added to a directory that HAS been visited within the client during that particular session, or, a previous session in which changes weren't submitted, or, do a one-time scan of materials that are checked out and flag those for internal monitoring, and then on quit, physically rescan the directories to validate if a change has been made, and if a change has been detected, alert the user to their missguidance, indicating to where the bonehead move is.

Basically, my theory of action would be to check every directory that the user has been in while the PSCM client is alive. If any file has been added that could be marked as a resource to be monitored by PSCM, have the client remember this path. Only one path should need to be routinely looked at (Perhaps when client becomes active), since this functionality is only a means to notify the user that something was created in a project somewhere, that it thinks should be monitored and checked into the SCM server.

[manu]

Hi Pontiac!

first, thanks for all the feedback and your time evaluating Plastic. We always learn from our users.

Things TC has that P.SCM doesn't:

1> TC has the built in ability to treat multiple item types as one item. For example, forms in Delphi are defined by one file, while the code to operate the form is written in another. The form is a DFM file, and the source code is a PAS file. The TC client visually merges these two file types as one item in the client, so when I do one check-out, both files get checked out at the same time. The Delphi project definition file has 4 files including the RES, DPR, CFG, and DOF. When checking out the DPR file, the RES, CFG and DOF file gets the same treatment automagically and are checked out at once. Having the option to customize what files should be grouped together, and what the primary file for this group should be would be tremendous and saves guess work in later projects. For instance, I could group Sqlite3.dll and coresponding unit wrappers together, share them (See next note) and source code and DLLs are up to date across all my projects. Flexibility is key, right?

This is perfectly doable using the before-clientcheckout trigger, you can create a trigger to manage the groups you are interested in.

Of course, it's better if the tool brings this functionality built-in but there are huge things that can be made using the triggers, this is one of them.

Things TC has that P.SCM doesn't:

2> TC has the ability to share files across projects and directories. Take for instance the SQLite3.dll again. You could have several projects that rely on this particular DLL. When you update this DLL in one project, TC updates one entry in its database, and the project you're currently actively working on is up to date. However, when you go to any other project that also shares SQLIte3.dll, the TC client will report that this file is out of date, and it'd be up to me to test the revision out. The perk here is that if I have a wrapper for SQLite3.dll that needs updating to reflect the changes in the DLL, I modify the wrapper in one place and check in the changes. Any other project down the road that I check-out will have the new changes, so I never have to remember to update the wrapper for the new DLL.

If you want to reuse libraries along repositories the answer is the usage of xlinks: http://codicesoftware.blogspot.com/2012/06/xlinks-and-branch-per-task-in-dvcs.html, http://codicesoftware.blogspot.com/2011/12/how-to-link-repositories-using-xlinks.html

Things TC has that P.SCM doesn't:

3> I've put my three votes on it, but, I'll add it here anyways... Having the ability to toggle seeing files that are intentionally being ignored Plastic would be awesome. When you set something to be ignored in TC, you don't see it. Its not managed, never checked in, always set with whatever file attributes it had when it was created. TC treats these files like the mother-in-law you never wanted, and completely avoids any interaction with them (My mother-in-law is pretty cool, just for the record). With P.SCM, I'm LOVING the fact that you can ignore files globally or on a per-project basis with just a few mouse clicks, and, then later on, permit files to be maintained in edge cases with a few mouse clicks. With TC, the functionality is there, but you have to go digging in the properties for the project and do some actual typing. Score for P.SCM.

I'm not sure why this one is inside the group "Things TC has that P.SCM doesn't" as you said you can easily ignore files in plastic, you can even go further and use the "cloaked" and "hidden changes" features.

Things that neither TC or P.SCM has, that I think should.

...

Basically, my theory of action would be to check every directory that the user has been in while the PSCM client is alive. If any file has been added that could be marked as a resource to be monitored by PSCM, have the client remember this path. Only one path should need to be routinely looked at (Perhaps when client becomes active), since this functionality is only a means to notify the user that something was created in a project somewhere, that it thinks should be monitored and checked into the SCM server.

If you use the Checkout-modify pattern the changed items search takes milliseconds in a 300K items workspace, a little more if you use the modify-commit pattern, it depends also in the HD.

I see your point in the warning when you are exiting the tool with pending changes, but honestly it's the first time I hear about this issue. I'm used to commit fast and often so I'm not facing this issue. Anyway you can add the idea into the user voice system, so, if more users find this idea useful we'll get implemented in the incoming sprints: https://plasticscm.uservoice.com/

[cidico]

Hi Pontiac, welcome to our community!

Good to see that I'm not the only one "in pain" using Delphi. I stopped using Delphi in 2003, so, long time no see...

I'm back to support a system developed in 1999 and I'm using Delphi 6.

Until now, I didn't have any problems using plastic with Delphi files.

What I could see until now is that Delphi only changes the files when it needs.

I've performed some merges here and everything is going just fine... until now!

Did you have any problems using Plastic with Delphi?!

Can you share those problems?

Thanks!

[Pontiac]

@manu - I'll reply when I have more brain power. Almost 18 hours of up time for me.

@cidico - I'm using D7. I had this gifted to me a few years ago from a company I had worked for. I'm no longer employed by that company, and I can't afford to upgrade, so, I'm stuck at this level! heh.

I haven't dug into much more than scratching the surface of PSCM. As Manu mentioned, there may be support for what I think should be built-in, but I have to get MUCH more familiar with the package. I've taken a couple of small utilities I've written for games and dropped them into P.SCM to see how my development process goes, however, I've not done much as far as checking in code and what not. I'm still a bit nervous about moving from one versioning package that I've used for years, to something thats 'smells fresh, but is it good?'. I really don't want to get entrenched in something with no real way to back out of it. So it'll either be my doing two commits to two different SCMs for the time being, or, I just scrap the idea of moving (Which I'm kinda hoping I to not do). Also, as I said, as a personal preference, I don't like using the IDE plugins due to a flakey VPN (OpenVPNs fault, actually) and locking up my IDE for extended periods of time, so I'll just be using the PlasticSCM client for my work.

But I'll report back when I dig in and do some real management with the system.

[cidico]

Well, if I can say a word about Plastic I've been using Plastic for 2 years and to me (as a .NET developer that I am) Plastic is the third best too (sorry folks, NHibernate just rock my world!!) ever created by man kind.

1st - Visual Studio

2nd - NHibernate

3rd - Plastic SCM

If you are afraid of been locked by this vendor, I must tell you that Plastic works with Fast-Import / Fast-Export. So, if you don't like (what I think you wont!), you can easily move to Git, Mercurial or any other SCM that handles FI/FE format.

Pablo is saying and showing some previews of Plastic interacting bidirectionally with TFS.

So, just wait to see!

SOOOOO, have some sleep and get back to see what Plastic can do to make your everyday programming better!

PS: I do not work for Códice (I wish I was, but they don't ). I'm a (very satisfied)free user of Plastic SCM Community Edition.

[manu]

Thanks for your feedback cidico!

It's always nice hearing from you