I noticed Pharo 9 was released past month (july 2021). I have several Pharo 8 images with packages and classes I created while learning programming in Pharo. Is it possible to just update the old image to the new version, or the standard way is to just File Out / File In, or use a change tracking tool like Iceberg to migrate my packages between images?
Common practice is to start every day with a fresh image, where you load (using Metacello and Iceberg) your code. Best practice adds CI/CD to that, so your tests are run every day against the latest stable version and the development image of Pharo 10, and on every commit of your code.
So add some git repos and commit your code from your old images there, so you can load them in new images
Related
I would like to back all changes in Xcode. Currently, I create project with the same name and replace it. Maybe it is possible in Xcode to do that in other, faster and easier way?
Use Time Machine, use git, or use snapshots in Xcode - if what you are talking about is making backups.
Time Machine is obviously a good idea even if you use git or snapshots so you get a backup when your hard drive crashes or you computer is stolen.
There is versioning - with Git support - XCode offers creation of a repository for you
by creating a brand new project
creating repo in Xcode menu -> Source Control
Here you can read a lot:
https://developer.apple.com/library/content/documentation/ToolsLanguages/Conceptual/Xcode_Overview/UsingSourceCodeControl.html
https://www.raywenderlich.com/51351/how-to-use-git-source-control-with-xcode-in-ios-7
According to atlassian.com, versioning explained:
Version control systems are a category of software tools that help a
software team manage changes to source code over time. Version control
software keeps track of every modification to the code in a special
kind of database. If a mistake is made, developers can turn back the
clock and compare earlier versions of the code to help fix the mistake
while minimizing disruption to all team members.
We host our own private NuGet Feed. I've noticed that when there are numerous versions of the same package, it can take a long time for the Package Manager dialog to display the packages in the feed.
If I move everything but the latest, or several latest versions, to an archive directory things seem to speed up. However, removing these old version makes it difficult for projects to update to the latest version.
What is the best practice regarding this? I'd rather not remove old versions, but I want to keep the feed responsive. Is there a way to organize the feed so that it only has to enumerate latest version of the packages but still has the older versions available?
Background information
These packages are part of applications that are under active development. If we discover a bug, we typically fix, test, and publish an update to the package ASAP so we can continue development. Because we don't have a formal release schedule, some times these packages are be updated several times a week or go months without an update.
I assume you are using NuGet.Server? This one gets slow as it is not optimized for larger feeds. It actually inspects all packages in your feed to obtain the metadata involved, every single time. If you have the sources (they are on http://nuget.codeplex.com) you can probably optimize and cache this, which should speed up things a lot.
You can upgrade to the NuGetGallery (http://github.com/nuget/nugetgallery) or use a solution like http://www.myget.org (private feeds hosted for you) or Inedo's ProGet (private feed hosted on your server).
One of the products which I have been working started some 10 years back. There were several developers who had worked for this project and several merges had happened throughout the life time of this project. Now taking the version information (clear case version tree), applying labels, checking out are taking long time. Is it a good idea to delete old branches and (say like 3 years back) to improve the maintainability of the code and performance of the version control? We're using clear-case as version control
If you are using ClearCase with UCM, then deleting a branch (which is only possible if you delete every versions on that branch for every file) isn't a good idea.
And with base ClearCase, it is still tricky and quite complex to properly remove everything.
Start first by obsoleting those branches and see if that speeds up operations like mkelem or lsvtree.
See cleartool lock -obs.
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
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.