views:

98

answers:

7

Wasn't really sure how to word the question ...

I have a project and I'd like to have a version with code for shareware registration, activation, etc. and another version without this added code (i.e., an unrestricted version).

Having created two different versions, however, I'd like to continue working on the overall project; if I update code for one version I'd like the code to be updated in the other version.

Is this possible? Is this what people mean when they talk about creating "branches"? (If the answer is "yes," then my question becomes "Is it possible to commit changes to one branch of a project and have the code simultaneously be committed to all branches?")

Thanks, as always.

+2  A: 

You can do this using branching, and most systems offer a way to script commits, etc. such that you can automatically propagate changes to more then one branch. You'll probably need to dig into the documentation for whichever system you're using for the details, though.

Hank Gay
+1  A: 

Yes that is what people mean when they say branches.

Often times you will come across merging issues, which is when you propagate changes across your environment, in the context of version control

Woot4Moo
+11  A: 

You could achieve this with source control branches, but it's probably not the best way to do it. A better way would be via conditional compilation:

void startup(void)
{
    do_some_stuff();

#ifdef RESTRICTED_VERSION
    do_check_activation();
#endif

    do_some_more_stuff();
}

Then you compile your restricted version with -DRESTRICTED_VERSION

You don't say what language you're using, but assuming it's a compiled language it's likely to have an equivalent to C's #ifdef / -D system.

RichieHindle
This is a better way to do it than version control. Keeping two versions in sync isn't really easy. If that's the only difference, you should compile the same code differently for each version (aka what RichieHindle says).
Adam A
Yes, that's probably a better way, but make you sure you regularly build BOTH versions, or you will end up with compilation errors in one of them you use less.
Yacoder
Yes, I'm using a compiled language--Delphi. Delphi has these compiler directives.
Al C
Another option is to just make the build system routinely compile *both* versions on a build run.
ndim
+5  A: 

No, this is not what branches were intended for. Branches are meant when you want to create a separate copy of the project and work on it without disturbing the other branches. You can merge from one branch to the other, but it's mostly done by hand. You might set up an automatic script that does it, but it would fail if there were conflicts.

I'd suggest you use a more fitting tool for this job. You haven't specified what language you are using, but most languages today support "conditional compilation". In C/C++ this would be the #define/#ifdef/#endif stuff. Thus you can turn it on or off by simply passing a parameter to the compiler.

Vilx-
Actually, people use branches to do this all the time. At one job I had, we had a branch of the main that included just the features that a particular client requested and paid for - any changes in main would get merged down to it, but nothing ever got merged up from it to main.
Paul Tomblin
Well, that still doesn't mean it's a best practice. :) Although, to be honest, I'm not very competent on source control best practices. Still, seems to me that conditional compilation is way more suited for this job than source control.
Vilx-
It entirely depends on how extensive the changes are, I think. If it's something that's going to take a few lines, sure, do it in conditional compilation. If it's a major new feature with dozens or hundreds of new classes, it should be a branch or something else that doesn't end up making your code hard to read and crowded with things that aren't used for the main product line.
Paul Tomblin
This isn't the case. If you actually have parallel versions of the product, then by all means go for branches! We do that too at my workplace. Same thing goes for version branches, ahead branches, etc. But the merging will be done by hand every time.
Vilx-
Look... I don't think there is a very definitive answer here about when to use conditional compilation and when to use branches. It's pretty subjective and either approach can work. All I'm saying is that in **my** opinion conditional compilation would be more suited for the OP's needs than branches.
Vilx-
+2  A: 

Depends on the language and source control used.

You can combine code for two different versions of a product by using compiler directives. In C#, it would look like:

#if shareware
  DoSharewareCheck();
#endif

In this case, if the product is compiled with the specified (shareware) symbol is defined, the code within #if and #endif is compiled. Otherwise, it is ignored.

Another alternative is to use branching in source control. You would create a branch which would specifically contain shareware code. The problem with this is that you have to regularly merge the branches to make sure your code in both is kept up to date. This is much more time consuming than using compiler directives.

Will
A: 

Yes, you can do this using branching, though you must be aware that the other branch is not updated automatically in general case, you can take your change to the first branch and try to "merge" it into another, but in some cases it can trigger a conflict with another change. Because your branches are different, there will be conflicts.

Yacoder
A: 

If you are working on a project by yourself, Git is a good choice because it has powerful branching and merge support built into it. It has kind of a learning curve, but it is not a bad choice.

fuzzy lollipop