I have two versions from a winform app:
a free version and a pro version.
sometimes I want to add a feature (or change) to both versions.
What is the easiest way to manage this changes on both version?
is there an easier way than TFS?
I would opt for having a single code base and using conditional compilation to produce the two versions. This way you do not even think of managing branches to separate free from pro.
What is the easiest way to manage this changes on both version?
Different branches for both versions (in any SCM), "Branch per Task" workflow (and finished task merged into needed branches, no changes performed in product-branches)
is there an easier way than TFS?
You can use any pure VCS with good branching support (TFS is more than just VCS)
Related
I'm working on a legacy SqlServer database with no version control. I've tried importing it into a VS 2017 database project, but it takes more than an hour to load ("your project will be ready after 1200000 operations are completed"), and usually crashes out in less time than it took to load.
Does anyone have any suggestions for a version control system I can try that will cope with real-life databases?
Baseline your Database and call this Version 0.1.0
As you need to make changes to it, like add columns, data etc. Script this and add this to the source control of your choice. Call this file something like:
Version-0.1.1.sql
As you make more and more changes the amounts of files will be added to.
Version-0.1.2.sql
Version-0.1.3.sql
Version-0.1.4.sql
Of course you will test these before you deploy to live. As you are working with what is a legacy system I would probably shy away from investment in expensive tools for what is a legacy system in the first place.
To bring a database to a particular version you would run the scripts in the order. Obviously in each script you have failover etc that handles anything that may go wrong within the scripts.
It is a manual process but the best points are it's cheap, easily to understand, does not require much expense and it's a methodical system to manage change.
Note: Obviously deploy scripts to a UAT version before directly on Live.
I have had a lot of success using flyway with both sql server and postgres. It allows you to create numbered versions as betelgeuce described in his answer, but also offers additional protection of ensuring your earlier versions haven't been changed before deploying any new changes
I'm in the process of developing a react app that will be deployed to two different places, one having slightly different and restricted "functionality" of the other. Think of a "freeware" version vs a "commercial" version type scenario.
I'm looking at using the DefinePlugin and if statements throughout the code to restrict certain areas from being compiled into the restricted version, but I'm not sure this is the best way to do it. As is always the case with React I'm always on the hunt for the best way to do something and I can't seem to find much info on this sort of deployment.
Help much appreciated!
You should consider managing these different versions of your application using code branches in your SCM. Using DefinePlugin might work, but will get hard to maintain down the road. This would also simplify things from a deployment standpoint as well.
Assuming you are using git, you could use the master branch for the "commercial version", and you could create a freeware-master branch for the "freeware version".
Then when you develop features in other feature branches, you can choose to merge them to master only, or both master and freeware-master via pull requests.
RPM seems to be pretty good at checking dependencies and handling individual file updates, but what is the best practice for handling cumulative updates to, say, a relational database across multiple versions?
For instance, say you have product Foo with versions 1.2.1, 1.2.2, 1.2.3, and 1.3.0. In each of these, there were database schema changes that required SQL upgrade scripts. Running each upgrade script in sequence is required to get up to the current version of the schema.
Say a customer has 1.2.2 installed and wants to upgrade to 1.3.0. How can one structure the RPM package so that you have the appropriate scripts available and execute the correct upgrade scripts against the database? In this instance, you'd want to execute the upgrade scripts for 1.2.3 and 1.3.0, but not the ones for 1.2.1 or 1.2.2. since those have presumably already been executed.
One alternative is to require upgrading to each intermediate version in sequence, forcing the user in this example to upgrade to 1.2.3 before 1.3.0. This seems less than optimal. Also, this would presumably need to be "forced" through external process, since I don't see anything in the RPM SPEC file that would indicate this.
Are there any known techniques for handling this? A bit of Googling didn't expose any.
EDIT: By "known", I mean "tried and proven" not theoretical.
Use the right tool for the job. RPM probably isn't the right tool. Something like Liquibase would be better suited to this task.
Can someone recommend a source control product that does all of the following:
Seamless integration into VS 2008 Pro
Will allow me to create different "editions" of a program (like "express" and "pro") - maybe with branching?
Will allow me to track changes for specific client requests. Say I have four clients, 2 on express, 2 on pro. I would be able to create specific, customized changes for all clients while still maintaining a singular codebase.
I'm not sure if something like VisualSVN can handle this, but there must be a product out there.
Virtually every source control will satisfy the #2 and #3 requirement with branches.
For #1 it's more tricky. If you really want a Seamless integration (capital S) then Team Foundation Server is your only choice. (It's very expensive)
Otherwise virtually all the major source control systems will have some sort of VS plugin, but the plugin usually doesn't work very well.
The two most popular free source control systems are:
Subversion
git
The best way to create different additions of your software using the same code in all of the different versions it to use pre-processor directives to conditionally compile your software based of flags that you set.
For information on conditional compilation please see the following links:
.NET: http://msdn.microsoft.com/en-us/library/9ae6e432%28VS.71%29.aspx
Java: http://weblogs.java.net/blog/schaefa/archive/2005/01/how_to_do_condi_1.html
C++: http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-Preprocessor-The-Code-in-the-Middle/3/
I hope this answers your question I use this alot when developing different version of applications for different platforms.
An example of this is an application that I developed in c# for both a server and mobile device implementation. Each had different ways of calling functions in .NET libraries but the logic was the same so I used preprocessor conditional compilation to compile to correct code for each platform but leave the logic intact.
From experience you only need integration with Visual Studio if you need to check out the file before editing it (a-la SourceSafe) and the file is read-only until then.
Having used SourceSafe I went on to using SVN and absolutely never looked back. Then I switched to git and again never looked back on SVN or Sourcesafe.
I can't comment on Team Foundation source control or Mercurial, I've never used those. At this stage I would recommend git over SVN as it's more suited to working with a single source tree that has minor changes between lots of branches. You can do the same thing with SVN but found the process of switching the working copy to another process painful.
Team Foundation Server provides the best seamless integration to VS 2008, but of course its not free (i agree that its very expensive)
have you tried using AnkhSVN? its got a pretty good integration for VS 2008 and SVN. so far it gives me the VS-SVN integration that I need, so you might want to check it and see if it fits your needs.
you can use TortoiseSVN, but I suggest installing CollabNet's SVN server, because AnkhSVN integrates seamlessly with it, plus you dont have to worry about major installations
It's only three months until VS 2010 is in final release (March 22, 2010). For MSDN subscribers, TFS will be integrated into Visual Studio (all levels except Express). MSDN subscriptions that include Visual Studio (any level) will include TFS with a one-seat license. TFS 2010 will run on Vista or Windows 7. SharePoint is no longer required, but you still need it if you want 100% of TFS features, like reporting.
It's all available now in beta; I'm running TFS on my laptop.
We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.
We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.
The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information :
the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).
This is where I need your collective wisdom :
How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?
What are the best practices around linking versions and bug tracking ?
Answers
It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.
Also to have each clone block the original bug make it a good way to trace the history back to the original submission.
Although I have accepted the answer I still welcome your input.
Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.
As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).
I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).
So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.
If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.
I was looking for a similar feature in TFS, and while doing some investigation, I found that there is an enhancement request to manage "sightings" in Bugzilla:
"Bug 55970 - (bz-branch) Bugzilla needs to deal better with branches (implement sightings)":
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
There is also a proposed design:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
For information, we are going to implement something similar in TFS 2010, with a "Bug Parent" or "Bug Master" to hold the information about the bug itself (repro steps, severity, technical info, impacted components...), that can have child of type "Bug Child" or "Sighting" that will hold the information specific to a given branch (target milestone, priority, specific information for that branch...).
We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.
Who uses versions and how do they use them?
How are versions related to milestones in a project plan?
We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.
After a short while we have many versions. Jira does allow us to control the list in two ways
1. Archive versions (greyed out from pick list)
2. Merge versions (rolls several versions together into a new version - no undo)
We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.
I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?
If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?
i'm going to ask a large question on this topic later on today, but I know the basic answer already:
- Depends on how your team wants to track things.
Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.
I have created a custom field (string) to list to version(s) (as V.M.P.B) where a bug has been fixed.
I have created also another custom field (string) to list to version(s) affected by a bug.
Doing that you are able to perform quick-search on specific version.