I've built a Rails 6 app that I want to
a) keep improving
b) use for multiple different projects.
I've tried to work out how to do this. One way seems the Engine route - eventually maybe I will go this route, but it seems like there is a lot to do and I want to start launching multiple projects now.
The only other thing I could think of is to have a separate git branch of each project, and perhaps use updates to the master to flow through to the other branches and the projects, but although I can't find anything that says "don' do that" I have a feeling it's because no-one imagined someone would even think of trying!
Are there any shortcuts to this? I'm maintaining everything myself (the projects the app) and I just want to use what I've build in multiple ways whilst I carry on improving it!
You can create a base git repo and then fork it into multiple repositories. While this might save you some time at the present it may cost you time in the long run as you have to merge changes from the base application into the forks (and vice versa) and handle resolving conflicts in each fork.
In the long run using engines to share common features together with application templates in the way to go. With engines updating the "base" functionality of the apps can just be done by bumping the version in the gemfile.
Like you said you can use a different git branch or you can use feature toggle pattern. Refer this link https://rubygarage.org/blog/separating-features-in-a-multi-tenant-saas-app.
We need to move from scrum template to agile template, we created a new project with the agile template, is there a way to migrate the product backlog item that we already have from one template to another?
The "easiest" way (and I use quotes for a reason), is to grab a copy of your existing team project WI definitions, grab a copy of the desired definitions (by creating a dummy project and downloading them), using something like BeyondCompare to compare the 2 sets of files, then making the appropriate changes. Yes, this is a very tedious process, but still better than the alternatives.
You can download/upload the WI type definitions using the command-line tool witadmin.exe.
You would need to add/remove/rename all the different fields between the templates. And eventually you will morph the Scrum project into an Agile project.
If this sounds painful, it is. But speaking from experience this is better than the alternative of trying to use something like the TFS Integration Platform to migrate data around. And don't be intimidated too much, while it is painful it is definitely do-able, and many people have done this before.
We're setting up a brand new TFS 2010 server, without having used TFS before (or, frighteningly enough, no other central source management system). Here's the general structure our small team (of 6-7 programmers) talked about setting up, and I'm curious, based on others experience working with TFS, if this is a good idea or not (these names are just descriptive and not what we're planning to use):
$/
Our Organization's Collection/
.Net technology projects/
class libraries projects/
Project 1/
Project 2/
Project 3/
etc.../
ASP.NET projects/
Project 1/
Project 2/
Project 3/
etc.../
Windows Workflow Foundation projects/
etc.../
WPF projects/
etc.../
Other non .NET source code/
SQL/
Server configuration/
(and so on)
Will we regret this structure after a year of using it? An application would span many parts of this structure - would that be a problem to manage?
At what level do we set up release/main/dev branches?
Thanks for any input and guidance!
Plan now. Branch when necessary.
With a team that has never managed branching/merging, I wholly recommend keeping everything as simple as possible to start (meaning, forget branching for the short term). After having recently converted our source from VSS to TFS2010 and implemented a Branch By Quality strategy for a team of a similar size with similar experience levels, my recommendation is this:
Do not implement a branching strategy until you need it. You can always branch once you determine it is necessary. Go ahead and bring the projects into TFS for source control and make sure everyone is comfortable with the software and the teamwork necessary to keep it stable.
In the meantime find members of the team who are interested and give them time to research, train, test, and practice on a parallel or simplified instance of your codebase. They will need practice creating projects, branching and merging in situations that mimic your deployment process; they will need time to communicate with the rest of the team to fine tune your processes and DOCUMENT them; they will need to be willing to be a resource to other members of the team as the learning curve flattens out. This way you have team members prepared and confident to step up and implement your chosen branching pattern.
You do not want to jump into a branching strategy before determining the need for it. There is a large amount of administrative overhead involved with plenty of perils.
With that said:
I don't think you will have any trouble managing what you have there once you start branching to accommodate a need. The key here is to make sure you don't over-architect this and complicate the management of your source/deployment. Also know that the structure of your TFS will be reflected in your local file system / workspace.
We created a separate Team Project for each independent solution or group of related reused libraries. In one case we grouped a set of highly dependent solutions together under a single Team Project - a large multi-application intranet portal that is deployed at once. Doing so allows us to keep deployment and source management simple. Here is a look at our branching structure for this one at a high level:
This is one large project with many sub-projects. Every branch is a complete copy (just the difference/versions are stored on the server). There are a large number of Team Projects above and below this one in the Collection and looks a lot like your list up top.
The final answer depends on the interdependency, structure, and deployment strategy of your applications. Do you have any specific concerns regarding your structure there?
In addition to #hangy's link, if its TFS 2010 your settingup then codeplex's Visual Studio TFS branching guide details the current wisdom for 2010.
Is there any guidance about workspace naming and workspace mapping in TFS (2010) ?
I'm not aware of any specific guidance on this, but after a couple years, we've primarily settled on a single workspace mapped to root $/. We've been operating like this for probably a year with 80+ developers, and haven't seen much of an issue.
In my opinion, this is valid, as is the idea of one workspace per Team Project, as long as you don't have a whole lot of Team Projects to deal with.
For the Mapping aspect there is nothing to add to the first answer as- "Map to root $/" approach seems to be the most used.
However, the MSDN Basic Guidelines for Creating a Workspace seem to suggest a different approach:
If you want to work with files from a single folder, map to one that is as close to the level of the team project collection as you can but no closer than you must. That way, you will get all the files that you need without getting many that you do not need.
I would tend to say that workspace naming conventions are only helpful if you need to create multiple workspaces on the same workstation. That would be the case if you need to work on different codebases hosted in different team collections or on different branches of the same codebase.
Like mentioned in previous feedback, I did not find a reference specifically addressing the topic, but the "Naming your TFS workspace" article from the old TeamPrise Explorer documentation has some good suggestions:
(...) give workspaces a name that includes your machine name, your deliverable, and branch if applicable.
"Deliverable" is organization specific, but can likely be related to a single team project so that the name of the project could be used to correlate the workspace to it (rather than using a different name for essentially the same thing).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I desperately need source control to manage projects between more than one developer.
A long time ago I used Visual Source Safe and it worked quite well.
What free substitutes can be recommended? I have the following basic requirements:
I need to host the repository on my own server.
I do not want extra clutter within my source files, like CVS does.
I need proper check in / check out, so that nobody can change a module until I've checked it back in.
I don't want / need source code merging / branching.
We use Delphi for web development, so many HTML files, images, SQL files, etc.
Any recommendations?
Git or Mercurial.
both are distributed and fast (each repository can act as 'server')
no extra clutter just one .git or .hg directory
you can pull changes from trusted or verified sources
I'll always recommend subversion with Visual SVN for server software and Tortoise SVN for the clients. You can exclusively check out files, so that nobody else can edit them, although that's not the default behavior. The only "clutter" it adds is a hidden .svn folder in every directory that is under version control.
If you insist on zero-clutter, and also free, you have limited choices. If you are open source, you can have a free copy of perforce. No clutter. SVN has clutter like CVS: a .something directory in each directory. git and hg just have one directory of clutter per clone.
If you absolutely insist on a checkout model, you have to give something up. P4 will do it, but none of the others will very well. Most people are more concerned these days with allowing disconnected operation than with a concept of locking. even svn lock only prevents checkin, not starting to modify.
There are other more obscure systems out there (e.g. arch) that you might look into.
I discourage the checkout/checkin approach. A decent version control system should be able to merge changes. This provides you with plenty of choices: CVS, SVN and Git.
As for "clutter" in your source files: I don't consider repository directories (e.g. .svn or .git) clutter, as this allows you to copy the repository structure.
Nevertheless, in SVN (not sure about Git) you can lock/unlock a file, basically mimicking the VSS checkout/checkin.
You should read a bit and learn a bit before you consign yourself and your fellow developers to living in the dark-ages of version control.
Visual Source Safe and the locking model of version control are dead. Most people have moved on. Those that have not are usually afraid of (or loathe) the idea of branching, and merging. Once they see that branching and merging can be easier, and more effective, then they can move onwards and upwards into a new world of version control options.
Ask yourself a few of these questions:
Would I like to separate the act of creating a new feature from the act of inflicting it on other developers, and on the final product (my live website)? If so, then I need branches. One branch = No effective version control.
Have I asked the other developers who will be working with me, what practices they find effective in multi-developer projects, and do they agree with me that locks are the way to go, or am I unilaterally enforcing my way of working with them? (You can have foo.pas for today, but try to get it checked in by 3 pm because I need to make a change to method bar inside foo.pas, later today.)
If I state that I want to make sure developers "avoid using old versions" do I have reasons for that other than that I hate or fear merging? Can we not think of any ways to prevent "using old versions"? Also, can we not think of any reasons when using old versions might be exactly what you have to do? If you used a non-locking tool like Subversion, why not say "please update before you commit". Then you will never have to merge, but if someone wishes to work with a non-changing version of the sources while developing the feature and then wishes to do the merging themselves, and you never have to merge yourself, you could insist that your work be done with locking (using subversion) but allow others the freedom to use a workflow that solves their problems, instead of yours.
Suppose (as you said in comments above) someone is removing something that you are in the act of creating. Wouldn't it be nice to see a complete list of his changes and say "I would like those changes gone, without removing other changes made by other people". This is known as working with "changesets" and is a key feature of DVCS like Mercurial (hg) and Git. In fact, the ability to prevent other people from modifying YOUR local repository willy-nilly, but rather making changes, which you can then review, and either accept or not accept will always be better at creating coherence on your (master) copy of the repository than any localized, centralized locking model can ever be.
W
You might like to investigate Team Coherence (http://www.teamcoherence.com). It doesn't create special folders and has a Delphi bent to it. For example, it groups .pas and .dfm files together by default. Help is excellent. It's also now free for a single license. I've been using it for years after previously using CVS and FreeVCS.
SourceGear's Vault is free for 1 user, and it gives you checkin/checkout plus merge-style operations. It also works totally clutter-free. I have been using it for some time and it works wonders. Transition from SourceSafe is especially easy, and integration with IDEs such as Visual Studio or Eclipse is very good.
Hmm, define "clutter" - to my mind a hidden directory per folder isn't clutter, frankly it hasn't been an issue at all (for reference, 7 years of first CVS then Subversion and prior to that VSS and something distributed the name of which eludes me).
Subversion is excellent and installation is almost trivial with VisualSVN server and use is straightforward with Tortoise as a client. Locking of files is an option, not a good one in the general instance but its there for binary files if you need it. This is probably the closest match to your criteria and I like it. A lot.
For personal use I'm playing with Mercurial - but not done enough to say more than that it works (and of course like most DVCS it fails your "lock" criteria). DVCS is different and has some issues.
If you have money, Vault (http://www.sourcegear.com) is worth a look - especially if you used and liked VSS since it started out as a "better" VSS though it has evolved somewhat. Worth visiting sourcegear just to read Erik Sink's thoughts on version control.
As for the rest, whilst I'm sympathetic to a wish not to (have to) merge stuff, writing off tagging and branching is pretty much the same as saying "I don't need version control" - it turns out not to be the case.
No one is recommending Bazaar, so here I am, I use it in my everyday work with Delphi projects.
It has a diff viewer that rocks, and that, for me at least, makes the difference with the other svn-like repositories.
I haven't used it for many years but I believe Jedi VCS meets all your criteria with the added bonus that it's written in Delphi and has some built-in smarts when it comes to handling dfm files.
We are using Fossil for source code managment of our Delphi programs.
It's very easy to use (if you like the KISS command line approach), and there is an internal web-based interface.
There is no installation needed, since it's only one executable to run. It's perfectly cross-platform: you can have your own repository on your Windows machine, then clone/synchronize it into any other server, running on Windows or Linux.
You can see our repository of Open Source Delphi programs hosted by Fossil on our web site. For internal work, I've found out that Fossil uses little bandwidth (much less than CVS or SVN), and is able to synchronize huge projects in a blitz, even via an ADSL or a 3G connection.
Here are some unique features, included in Fossil (with no third-party component to setup):
Bug Tracking And Wiki
Web Interface
Autosync
Self-Contained
Simple Networking - Fossil uses plain old HTTP
CGI Enabled - No server is required to use fossil.
Robust & Reliable
I would recommend Plastic SCM: http://www.plasticscm.com/
the best (?) merging and branching support!
but you can also use single branch + exclusive checkout (aka lock)
very nice and handy GUI
free up to 15 users
very good support (within a day, mostly within an hour!)
very modern, automatic merging and branching, distributed, etc
Delphi plugin available: http://code.google.com/p/plastic4delphi/