I created a baseline in my workspace and forgot I had some undelivered changes. These changes are not supposed to be part of the baseline.
The changes and baseline have not been delivered to the stream, is there anyway to get rid of this undelivered baseline and undelivered changes?
Would deleting the workspace and creating a new one work?
This thread is clear:
Both the internals and the users of RTC SCM system depend on the fact that a baseline is immutable.
A baseline is visible (via various search menus) as soon as it is created, so it would not be safe to change the content of a baseline, even if you haven't yet delivered it.
That is why RTC makes it very fast and cheap to create a new baseline whenever you need one.
BUT I agree that you should be able to:
drop a baseline from your outgoing changes list in the Pending Changes view (Story 18512: Discard a baseline: nothing done yet 8 years later) and:
hide/archive a baseline:
Enhancement 170855: Provide the ability to hide (archive) baselines that are no longer needed, 2011, reformulated in
Enhancement 169438: Need true database archive and restore capability for work items and SCM objects: 2011, itself encompassed in
Enhancement 294112: Archival techniques and tools: 2013.
Nothing is done yet.
So try simply to:
rename your current baseline with a name which makes it clear it is not meant to be used,
create a new baseline including only the change sets you want
deliver both baselines
Related
Unfortunately this is a very general question...
Imagine an authoring application to create e.g. electric schematics. Engineers draw schematics until they are satisfied with their product and it's ready for production.
At this point a "Revision" would be initiated (say Revision "#1") . From now on all data/documents of this revision can't be changed anymore. It's read-only.
As time goes by, the engineers have smart ideas and start to update the existing schematics based on Revision #1. They add new features, remove features, replace some components with newer versions etc. until they have a Revision #2.
A common requirement this then: What has changed between Rev.1 and 2? Some delta reports are needed.
What would/could that mean with RavenDB?
If the engineers start a new revision, would that mean to
copy all documents and insert them with a new Id like
"/proj-1/rev-2/component-1000"? How would I update my relations between documents
then? Adjust all relations "manually"?
Snapshot the DB? Can I compare a snapshot DB with the current DB?
How would I find all the delta between those revisions?
If I do not copy all documents or snapshot them, would I need to book-keep all changes in separate documents (event-log style) i.e. DocX has been deleted, DocY has been updated with Value1, DocZ has been added etc?
I know that RavenDb has its own revision system. It's based on single changes of a document. Could this be used for advantage here?
Any hints how to model such a system would be highly appreciated.
RavenDB has the notion of revisions for documents, which create read only snapshot of the document. They are created whenever you modify the document.
For your needs, I would recommend creating: plans/1238-A as the document itself.
Whenever you need to stamp a read-only revision, use: plans/1238-A/revisions/1 or something like that.
I would recommend not modifying any references, point to the same location, but when reading the revision, ask the referenced revision.
I'm a brand new to Accurev and I'm having many troubles with it. One of the developers I'm working with has promoted bad code (things are now broken that weren't before) for 2 months on a stream, and I'm wanting to get a copy of the original code before any changes were made to it.
I currently have a workspace, and whenever the other developer creates code, I pull his changes into this workspace attempting to fix the bugs. These changes are promoted to an existing issue within Accurev.
Is there any way I can perhaps create a second workspace and obtain a copy of the original code (before any changes were made)? My target date is March 14th.
I would suggest you revert or demote the bad code that was promoted into the stream (Depending on what version of AccuRev you are using). This would put the stream back into the state it was before the promotion occurred.
Below are some suggested readings on the related topics.
Best way to "un-promote" files in Accurev?
https://community.microfocus.com/borland/managetrack/accurev/w/wiki/26745/purge-revert-and-demote
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/25951/how-to-revert-changes-in-a-stream
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/26079/what-is-the-proper-way-to-revert-by-change-package
As an alternative, you could create a time-based stream below the one with the bad code. Set a time basis that predates the bad promote.
To do this, I right-clicked the stream >> New Snapshot.
I select "Specified" and enter the date (with a relative time).
From the Snapshot, I created a New Workspace which was then populated with previous code.
Hope this helps!
I have a file in RTC (call it foo.c) that I modified and checked into a changeset (CS1) along with some other changes. I then modified that file again and checked it into a different changeset (CS2) along with other changes.
I've now run into a case where I want to deliver CS2 to a stream, but RTC is giving me an error that delivering that would create a gap in the stream (because of the change in CS1). I don't want to deliver all of CS1 yet, because it contains some changes that shouldn't be in a build yet. The original change to foo.c in CS1 was a minor removal of a #include, and doesn't affect anything else.
Is there any way to resolve that gap?
I see some stuff in the RTC documentation about applying patches, but I don't understand where it's going with that.
Is there a way to split a changeset into multiple changesets, which would allow me just to deliver the one file?
Problem: CS1 changes foo.c, CS2 further changes foo.c. You only want to deliver CS2, but RTC tells you that would introduce gaps.
Solution: Create a patch from CS2 and suspend both CS1 and CS2. Then apply the patch, merge it into your workspace and check-in the changes which will create yet another change set, CS3, identical to CS2 but with no dependency on CS1. You can now deliver CS3.
After delivering CS3, you can discard CS2 and resume CS1 which will require you to merge with CS3.
Then you should be in the state that CS1 builds on CS3 and you can choose whether or not to deliver CS1 in the future.
Update since 2012 (and the original "workaround" of delivering everything and reverting what you don't want):
See this thread:
In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes).
In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes.
This means users will not have to accept the change sets 'as a patch'.
Applying change sets as a patch has limitations compared to the new workflow.
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page.
Below are some videos which show this feature:
Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE
Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE
That is the Locate Change Sets feature:
In RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page:
The classes that are involved for filling the gap include (available in RTC 5.0):
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)
Both features are explained in detail in the "Improved Gap Handling for SCM" article.
Original answer (2012)
Is there a way to split a changeset?
I don't think so, reading the changeset man page:
A file or folder in a component cannot be part of more than one active change set.
When a file or folder is included in an active change set, all changes to it become part of that change set whether or not the change set is current, and changes to that file or folder cannot be explicitly checked in to a new change set until the active change set that includes it is completed.
Having foo.c in CS1 and CS2 means CS1 has been "completed" (frozen, in essence), and it would be bad to try and split it.
The patch solution means:
cancelling CS1
adding the additional change to foo.c to CS2
redoing CS1 changes
See "How do I remove a change set from a stream?"
Story 149483 is about enhancing that cumbersome workflow, and the gap detection is being enhanced (Enhancement 24822)
The OP timwoj concludes:
I ended up just delivering all of it, then reversing the one that I didn't want.
I accidentally created a baseline for a component in my RTC stream and also delivered it. I was wondering if there is anyway to delete the baseline or undo the baseline. If anyone could please help I would really appreciate it.
You can't delete the baseline but you can rename it to indicate your mistake e.g. don't use.
You can go to your stream an replace the component with the previous baseline. (note: anyone else that's already accepted it will then see it as an outgoing change and may delivery it again).
You can create a reverse patch and deliver that to undo the changes the erroneous baseline delivered.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.