Pin/Rollback from Command-Line Client

[Nihimon]

We're trying to automate a Deploy/Abort process using Pin and Rollback but the Command-Line Client doesn't seem to support Rollback. Are there plans to add this feature? Or have I simply over-looked it?

[Beth]

We currently don't have a rollback command in the command-line client. I have a feature request open for that functionality that I can add your "vote" to if you would like.

F; 14330

[Nihimon]

Please!

We are trying to keep a "Base" folder structure in Fortress that matches our deployed scripts/programs. We share from this Base to our Dev folder structure, keeping the base Pinned to what's been deployed.

When we Deploy what we've worked on in Dev, we want to be able to automatically add or re-Pin the files we've been working on.

Likewise, if we Abort a project, we'd like to be able to automatically Rollback any changes we've checked in that didn't get deployed.

[AjarnMark]

While waiting for the new feature, couldn't you accomplish your goal through branching and merging?

Just thought I'd throw out the idea for consideration. The way we do it is that in our project folder, we have a TRUNK and a BRANCHES folder. TRUNK is where we do active development. At the point that we we are making a cut to deploy (in our case, we do this on our first release to the QA group) we create a branch from TRUNK into a new folder underneath BRANCHES. Any fixes that come back are handled in the branch and then, upon release to PROD, merged back into TRUNK. The branch then represents the PROD version. We also apply a label at the top of the branch whenever we do a cut (such as a PROD Hot-fix) so that we can always get back to the PROD GOLD version by doing a GET from the label if there was other hot-fix work being done. Meanwhile, development work on the next version can proceed in TRUNK. With this setup, we have not had a need for PIN (although one may exist we just haven't run into) and we only use Rollback sparingly for the "OOPS that change was completely bogus and should be eliminated as if it never happened" on the occasional single file. We also apply labels in TRUNK on each branch/merge operation, so if you really wanted to abort an entire set of work, you could.

Side note: We previously had this inverted and tried to keep one folder (TRUNK) to always be the PROD release and merge things into it as we went, but this led to some merging nightmares at one point, and with counsel from SourceGear, we flipped our process around to the above.

[Nihimon]

I've read everything I could find on this, and I understand your setup, but I'm not really sure it would work well in our situation.

What you describe would work well where you have well-defined, persistent units of deployment, such as Visual Studio Solutions (or even Projects). However, we have a large body of database scripts (stored procedures, views, etc.) that can't really be combined into a single unit of deployment that doesn't change over time.

Imagine we have projects Alpha (view1, view2, sp1, sp2) and Beta (view3, view4, sp3, sp4) deployed. Now I need to make a change to view1 and sp3. Meanwhile, my colleague is making a change to sp1 and sp2. I need a way to deploy *only* the files I'm modifying.

If I used the method you describe above, and then went looking for the "Production" version of sp4, I'd have to check through a lot of different Branches looking for it.

In short, the method described above works great for well-defined Projects that don't really overlap, but that's not our situation at all.

However, if you have any other sources of information on best practices with this stuff, I'm all ears

[Beth]

I have other customers using the share-pin method of deployment for their particular scenarios. Without looking closer, I couldn't say if that's the best way to do it here or not. The one benefit you would obtain is that after merging, you only have one big changeset that needs to be rolled back, and for some that's a bit easier to deal with.

Going in the same vein as you already are though, I have a work-around kind of rollback that may work well for you. If you would like instructions, send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread and let me know.

(Email received)
(H: 216104)

[Nihimon]

Thanks for the suggestions but I'd still like to encourage you to implement Rollback in the CLC.

As I tried to explain above, we don't really have a convenient way to deal with Folders. Rather, we almost always are dealing with an arbitrary group of individual files that may or may not have been grouped together before. As such, Merge is just not possible.

While it's possible for us to do the Check-Out, Get to a different location, copy over and Check-In, it would be a lot more convenient if we could just Pin or Rollback to the appropriate version for each file in our deployment.

[Beth]

I understand and still have the feature request. Even though I've presented a work-around, I won't remove the feature request. It was just a suggestion so that you can continue forward instead of holding your work up for the feature.