I have a branch of a large project with a couple of change packages on it. I would like to undo one of them. In Subversion, this task is trivial, esp with a tool such as tortoisesvn - select the revision(s) from the history and undo the changes. I cannot find a way to do this in MKS. I cannot even find a way to traverse my sandbox to an earlier revision. Can anyone please offer some guidance? I'd rather not have to create a second sandbox, diff the two trees and copy select changes from one to the other, which is what a colleague (who wanted to do the same thing) suggested.
Unfortunately, this functionality does not currently exist in Integrity.
Disclosure: I work for PTC Integrity Technical Support.
#mlizak_PTC
Do you then know somethig about
Change Package->Discard
Discard Change Package Entry...
Somehow the help to the change package functions did not enlighten me :)
#Jon
The only way I know to get the same as "traversing the sandbox to an earlier revision" is when you have a well defined checkpoint resp. project revision which you can retarget your sandbox to (build sandbox) and then resync.
You can then retarget your sandbox again to the state it was before (Mainline or a variant) and see the differences to the current state of the project.
If had to rely on changepackage info I would redirect the output
of the command 'si viewcp' to a file and try to sort that information out.
eg.
si viewcp --fields=configpath,creationdate,id,location,member,membertype,project,revision,sandbox,state,timestamp,type,user 132:1
From the gui you can also select all entries from a change package detail view and copy them to clipboard.
Related
I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.
I have an app in the iPhone app store and have released several minor updates to it. I want to begin work on some major feature additions and reorganization, but don't want to lose the source code of my most recent version in case everything goes horribly wrong.
Should I start a new Xcode project from scratch and copy my existing source in? If I do this will I be able to submit the build from this new project as an update or will Apple complain that the build comes from a different Xcode project?
I've seen (but not used) Xcode's "Snapshots" and "Source Control" features - are these what I'm looking for?
Any help or direction greatly appreciated.
I would suggest getting your project into some kind of Source Control. The popular ones these days are Subversion (Xcode has built-in support for it, but the support is pretty crappy), git, and Mercurial, all of which run great on the Mac.
You would add your project to a git/svn/hg/etc repository, and then "tag" the repository with something meaningful ("Shipping Version 1.3" or something) (alternatively you could just branch your project at its current state and give that a meaningful name). Then you can do your developments, add and commit the changes to your repository. If you need to revert back to your old shipping version, that's quite simple because you tagged it before you started work (think of a tag like a snapshot).
The other option is to start a fresh Xcode project and copy things over. I have personally done this and shipped just fine to the App Store (just make sure things like your app's bundle id "com.whatever.app" matches with the original one, and make sure you codesign properly) and you're good to go.
Having said that, unless you have a really great reason to start with a fresh project, you're probably better off using source control management with one of the aforementioned tools (git is my preference).
You are using some form of source control right? If not, stop what you are doing and make sure to set up an svn repository. Svn is bundled with your mac and integrates with Xcode.
You also may want to start thinking about doing backups...
I highly recommend you check out Git. There is great Git support built into XCode 4, and you can use Git just fine with XCode 3 as well.
One great thing about Git is that you do not need a server to take advantage of the source code management features. It is a lot easier for a solo developer to work with than SVN once you get your head wrapped around it.
I also highly recommend GitX - a free graphical UI for Git that is absolutely amazing.
One other recommendation it GitBox - a simple tool that allows using a Dropbox as a Git master repository. This is great for sharing code between multiple machines without needing to have or pay for Git hosting at GitHub or elsewhere.
You can either do what the people said before, and use svn git or the like, OR if you don't want to mess around with any of that you can simply create your own version control by copying and pasting the folder and name it "project name x.x" and modify the version without the version number on it
snapshots are the first step. when you are comfortable with them you can hook up to an SVN server for your offsite backup
just make a snapshot after your distribution build and label with the version number
The quickest, easiest, short-term solution is to select the Xcode project folder, and duplicate it. This will create a duplicate of everything in the project. Apple won't care that it comes from a duplicate project.
For the long term, look into setting up an SVN. This will help you save your previous versions every time you make changes.
Since you are new to source control management so might I suggest using Subversion.
Subversion has less features than Git, but you don't have the confusion between pushing and committing (locally vs remotely) and you will find there is more software that supports Subversion than Git or Mercurial.
If you need a quick backup, you can always zip the current working folder for your Xcode project, then name it something like:
MyApplication-Version-1.00.zip
I am starting to get a reputation at work as the "guy who breaks the builds".
The problem is not that I am writing dodgy code, but when it comes to checking my fixes back into source control, it all goes wrong.
I am regularly doing stupid things like :
forgetting to add new files
accidentally checking in code for a half fixed bug along with another bug fix
forgetting to save the files in VS before checking them in
I need to develop some habits / tools to stop this.
What do you regularly do to ensure the code you check in is correct and is what needs to go in?
Edit
I forgot to mention that things can get pretty chaotic in this place. I quite often have two or three things that Im working on in the same code base at any one time. When I check in I will only really want to check in one of those things.
A few suggestions:
try work on one issue at a time. It's easy to make unrelated changes to the codebase that then end up being committed as one big chunk with a poor log message. Git is excels here since you can so easily move switch branches, and stash and cherry pick changes.
run the status command before a commit to see which files you've touched and if you've created new files that need to be added to version control.
run the diff command to see what you've actually changed. Often times you find that you've left in some debug logging that should be taken out or made some unnecessary change that is just cluttering up the diff. Try to make your diffs as small and clean as possible.
make sure your working copy builds with your changes in it
update before checking in and make sure that your working copy builds with other peoples changes in it
run what ever smoke test suite you might have to make sure that your changes work correctly
make small and frequent commits. It's a lot easier to figure out what has broken the build when the breaking commit is small.
Other things that the team can do is setup a continuous integration server like David M suggested so that the broken build is discovered as soon as possibly and automatically.
I usually always do a Get Latest before, then build. If build is good then I check in my code.
Here is what I have been doing. I have used ClearCase and CVS in the past for source control, and most recently I have been using Subversion and Visual Studio 2008 as my IDE.
Make my code changes and build on the local machine.
Make sure they do, in fact, fix the bug in question.
Run an SVN update on the local machine and repeat steps 1 and 2.
Run through the automated unit tests to verify that they pass.
If an automated smoke test is available, which automatically tests a lot of the system's capabilities, run it. Verify that the results are correct.
Then go to the build machine and run the build script.
If the project's configuration has changed, this could definitely break a build. Perform an SVN update on the build machine, whether the build script does that or not. Open the build machine's copy of the IDE, and do a complete rebuild. This will show you whether the build box has any problems that you have taken care of on your machine but not on the build box.
The suggestions to keep separate branches for each issue are also very good, if you can keep track of all of the issues you are working on.
First, use multiple working copies (a.k.a sandboxes) - one per issue. So, if you've been working on some complex feature for a while, and you need to deal with a quick bug fix on the same project, check out a new clean working copy and do the bug fix there. With independent working copies for each issue there is no confusion about which changes to commit from the working copy to the reposistory.
Second, before committing changes, always perform the following three steps:
Buld the software.
Run a smoke test (does it start and run without crashing).
Inspect the changes you're checking in by diffing your changes against the baseline.
These should be repeated after any merge operations (e.g. after an SVN update).
At my workplace, the safety net for this is peer review. That is, get someone else to build, run, and reproduce your solution on their machine, on their view.
I cannot recommend this enough. It has caught so many omissions, would-be problems, and other accidental pieces of junk to make it a valuable part of the process. Not to mention that the mere knowledge that you have to place your work in front of someone else before having it go on to the main branch means that you raise your own quality standards.
In the past I have used branching in Clear Case to help with this issue. The process I used is below. I've never used SorceDepot so I do not know how this can be adapted to work with it.
Create a branch for the bug fix
Code all changes on the branch
Code Review
Merge to stable branch in a different view (the different view is important)
BEFORE checking in: compile, test, and run
Check in code to stable branch
By creating the branch and then merging the changes to a different view (I use Merge Manager to do the merge) any files that were not included or checked in immediately cause issues. This way everything gets tested as it will be when checked in on the stable branch.
The best thing to avoid your problems, is to use hooks, that are provided in most SCMs (they are for sure in SVN and Mercurial, and I believe they must be in other advanced SCMs). Attach unit tests to the hook and make it run every time someone checks code in - exactly before it is checked in. This way you will achieve two things:
code in SCM repo will always pass the tests,
you won't make most simple mistakes, because they should be easily detectable, if you have decent test suite.
I like having Tortoise plugins for Windows Explorer. The file icons are all badged with committed, modified or not added icons making it very easy to see what status the files are in. I also enable the meta data for Modified so I can sort changed files in the list (Details) view, where they bubble to the top so I can see them.
I bet there is a Tortoise* plugin for your SCM, I saw one for Mercurial and SVN (and CVS, ugh). I really wish Mac OS X's Finder would accept plugins like Tortoise, its so much easier than having to pop open a dedicated app most of the time.
Get someone else to go through "every" change "before" you check in the code.
I once ran across a commercial tool for Windows that allowed you to "stash" code changes outside of source control but now I can't remember the name of it. It would copy the current version of a document to a backup location and undo your checkout in source control. You could then reintroduce your backed up changes later. I believe it worked with multiple source control systems. Does anyone know what program I'm trying to describe?
The purpose of my asking is twofold: The first is to find a good way to do this. The second is because I just can't remember what that darn program was and it's driving me crazy.
Git: http://git-scm.com/
You can use git stash to temporarily put away your current set of changes: http://git-scm.com/docs/git-stash . This stores your changes locally (without committing them), and lets you reintroduce them into your working copy later.
Git isn't commercial, but is quickly gaining many converts from tools like Subversion.
I think the product you're thinking of is "CodePickle" by SmartBear Software. However, it appears to be a discontinued product.
The term that seems to be used for the type of functionality you're looking for seems to be 'shelving'.
Microsoft's Team system has a 'shelve' feature.
Perforce has several unsupported scripts, including p4tar and p4 shelve
There are several 'shelving' tools for Subversion, but I don't know how robust they are.
I'm no git user myself, but several of my colleagues are, and they seem to like it precisely for this purpose. They use the various git wrappers to commit "real" changes to the SCM system used by their company, but keep private git repositories on their drives which they can keep their changes which they don't necessarily want to commit.
When they're ready to commit to the company's SCM server, then they just merge and commit upstream. Is that what you're looking to do?
Wouldn't it be a better idea to store your private changes in private branch, using e.g. svn switch to change to main branch whenever you need to?
Mercurial has the Shelve Extension which does what you want.
You can even select which changes from a single file that you want to shelve if you really want.
In Darcs, you either don't record the changes you want stashed (it asks you about including each change independently when you record a new patch), or put them in separate patches that you don't push upstream.
There's no need to fully synchronize your local private repos with public/upstream/other ones. You can just cherry pick the patches you want to push elsewhere. Selecting patches can also be done with patterns, so if you adopt a naming convention for your stashed patches you can push everything but them easily.
That way, your private changes are still in revision control, but they aren't shared until you want them to be.
I found an excellent article about obtaining similar functionality using Subversion branches:
Shelves-in-subversion
And then there's the old fallback... 'patch', or even the old "copy everything to another location, then revert".
Both of these are less convenient than using tools that are part of most VCS systems, though.