I'm using Gitkraken's gitflow:
https://support.gitkraken.com/repositories/git-flow
My fix basically requires changing a single HTML file, a class on a single element. I also want to change the version number in my app (it's a Windows store app, changing the package.appxmanifest file from 4.1.2 to 4.1.3).
My intuition is to (a) start the Hotfix branch, (b) commit the HTML change, (c) another commit for the version change in the appxmanifest file, and then (d) finish the hotfix, merging it into Master and Develop. Is that correct? If not, what's the order of operations?
Most probably You've found the answer during this time, but in case someone else finds this page then this answer might be helpful:
If this is an urgent fix for critical, out-of-cycle releases into production as Hotfix stands for, then yes, this is correct order.
In case it's a fix that can wait for future release then this should be handled as regular development and next order should be used: feature->develop->release->master
Related
I have this patch developed for mailman-2.1.13, and I would like to port it to mailman-2.1.15
I never did this before, so I'm asking for advices here. How would you go about this task ? Here are my thoughts on the subject :
I could search the 2.1.15 codebase for code segments corresponding to the patch, but I would miss any new part depending on the patched code.
I could look at the diff between 2.1.13 and 2.1.15 and search for parts conflicting with the patch, at the risk of drowning into the many changes between the versions
I could simply rewrite the patch but I would need to understand all the logic of the patched application, which could be quite long ...
Your advices are welcome !
The keywords for search are "rebase", "merge" and "conflict".
A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other.
You would find that resolving conflicts (e.g. porting patch to newer version) is usually not trivial operation and cannot be done correctly without deep understanding of code you work with.
Really depends on the change in main code base from mailman-2.1.13 to mailman-2.1.15, but sometimes it is easier to rewrite patch from scratch, sometimes it is sufficient to merge changes from patch to new version and try to fix the conflicts/problems it makes.
I would start with finding out what was the original problem that patch wanted to solve and how it was solved. Then look to 2.1.15 code and find out if the original problem is still there and if it is possible to apply the patch directly (internals didn't change so much in meantime) or new approach must be applied.
I am new to Plone and trying to learn how to setup and maintain a server. I realize I need to develop a schedule for packing the data. Right now I am just trying to test this using the pack function in the Zope control panel and also the command line (bin/zeopack).
I know in practice I should leave a week's worth of history, but if I pack to 0 days shouldn't I see all edit history disappear? I am not seeing this happen. What am I doing wrong?
You may be confusing the "undo" history with the version history. Packing the database gets rid of old, unused data. That eliminates your ability to undo older transactions.
Version history is not the same. Version history is not considered unused data, and is not eliminated in packs.
If you don't want edit history, turn off versioning.
When we were using SVN, we'd always print at the footer of our pages: "Revision XXXX". I've been looking, but I can't figure out how to do the same thing with TFS. Can anyone offer some pointers?
In case this matters: we're using ASP.NET MVC. I'm guessing it doesn't matter, however.
You can use the default version system for assemblies to track revisions number without adding anything in TFS.
If you use the Major.Minor.* format in your AssemblyInfo's AssemblyVersion attribute (e.g. [assembly: AssemblyVersion("1.0.*")]) it will generate a version according to the following format:
Major.Minor.Build.Revision
where
Major = Your value
Minor = Your value
Build = Number of days since
2000/01/01
Revision = (Number of seconds since midnight on the day
specified in Build) / 2
This will give you an always increasing number which gives you precise information on build date and time.
To use these values in your code, you can simply recover the version using Assembly.GetExecutingAssembly().GetName().Version.
You can update version number of projects in AssemblyInfo.cs using assembly versioning tools/techniques like this. Version number of an assembly can be updated based on TFS changeset number. Version number then can be displayed in application.
At least when it was released, TFS didn't allow symbol replacement in files which is what I think you're after. I'm not sure if that has changed in more recent versions.
Changeset != Version
That being said, you can add a setting in web.config that holds the version number, and display that on the page. The version number can be updated as part of the build process, but it will not correlate to a changeset.
I should probably add that this can become a circular problem. If you get the latest changeset number for a project, then add that to the config (as named above), then checkin, you are no longer displaying the latest changeset. Adding 1 to the latest changeset is not a guarantee either, because something can be checked in while you are updating the files.
We ended up using a MsBuild task that searches for a particular string and replaces with the appropriate value (not necessarily the revision number).
The task runs as part of our build templates and puts the revision number in all the files that have the token present.
My team now has an SVN + Ankh setup in ASP.NET with trunk, branches, and tags. We switch branches and work on code, but many times there will be inexplicable conflicts in files after simple changes. Why is this? I suspect we simply don't understand enough of how this works. Are there any do's and don'ts, or how should we be approaching our daily changes and commits, without causing conflicts? Is there a basic pecking order of operations to perform to achieve SVN zen? Are we updating before committing or something? Any help is greatly appreciated.
Always update before commit. If you really work with branches don't use switch or only if you really undstand the switch command and how it works otherwise checkout a branch into a fresh working copy in other words create a new one.
Always branch, merge on the solution element, make sure you're fully up to date before merging (ankhsvn will warn about this), also make sure you have no modified files before merging.
Read up on svnbook for when to use normal merging and when to use reintegrate.
Finally, if a conflict does occur, make sure you have a good 3way merge tool to solve the conflict. AnkhSVN recognizes a lot of them automatically, but I really like source gear diffmerge
what's your strategy to increase build number?
Most software has a hierarchy of version numbers:
The "marketing" version number (like "Windows 7")
The major version number - usually incremented when there's a major new version that breaks some compatibility with a previous version, adds a major new capability, requires purchasing an upgrade, or more.
The minor version number - upgraded every time there's a bug-fix or minor feature enhancement that's released to the public
The build number - this should be incremented every time any change is made to the program, so that if someone finds a problem in a nightly build or beta-test version, you can identify exactly which version was being tested. This number is often a revision number directly from your version control system like Subversion, or a timestamp, or something similar that makes it easy for you to roll back the code to that version if necessary.
All the dlls must have the same version number for one release.
Build number consists of "MajorVersion.MinorVersion.BuildNumber.Revision", usually I keep the Revision Number to be 0. Only the first 3 numbers are changed.
For every nightly build, BuildNumber will be incremented automatically. I will manually increase majorversion and minorversion if the changes are sufficiently big.
Every checkin should be tagged a version, use the subversion current version as the part of the build exe version.
It's quite reasonable to increase the build number for just every build. This way testers can tell more exactly which build they find a bug in and when it is verified to be fixed.
We have a build number that's incremented on every build (formal or otherwise). We use a CruiseControl.NET labeller for this.
We have a version number that's incremented by hand only on formal releases, and we define that centrally in one of the CC.NET scripts, which are held in source control.
Like everyone says, increment the build number for every build. We set the major/minor numbers by hand when we do a branch, a branch is usually done a few weeks before release, then that branch gets regression tested. Builds done on the branch still get incremented though.