Hey all,
I’ve run into an interesting scenario that I think some of you might
have
some suggestions on. I am currently working on a RoR project and we are
making full use of the migrations. We are also using a subversion
repository
for our source control. Now, the problem…
We are both making migrations and checking them into SVN. So, if in our
checkout we have migrations up to 10 and we each make one, we both now
have
the 11th migration. So, when we check-in, there are no problems and
things
workout just fine. But, after a checkout and a “rake migrate” a problem
occurs. Since there are now two 11 migrations, the migrate barfs and
dies.
My solutions so far look like this:
- Manually make sure that the migrations are numbered in numerical
order
- Some how figure out a way to check and see if there has already
been an 11 when doing a commit and make it the next available number
- Check in migrations right away and make sure to check the repo
often to make sure your migrations are up to date
The last option seems to be the best at the moment since a migration I
make
may effect the migration of another developer. But, what I am curious
about
is how other people in similar situations handle this situation. What
are
some options that are available to me?
Thanks in advance,
Ryan
My solutions so far look like this:
may effect the migration of another developer. But, what I am curious about
is how other people in similar situations handle this situation. What are
some options that are available to me?
Seems like the last would work, but it doesn’t for us. What happens is
that you check it in, put in some initial stuff (or nothing at all), and
start fleshing it out. Then someone else puts in another migration,
finishes it, checks it in, and does a migrate. They are now past your
migration which is still unfinished.
Yes, they could go back and then forword again, but that can get messy
depending on what the migration is doing…
We’ve found the best way is to create it, don’t check it in, work on it
till it’s good, then update, check for any conflicts and check it in.
Not the best, but it’s worked pretty well for us.
It would be nice if there was a way to track all migrations individually
and somehow specify which are dependent on others… a lot of our
migrations don’t rely on one another so could get run in whatever
order…
-philip
Hi there,
Since there are now two 11 migrations, the migrate barfs and dies.
How about making migrate work with 2 migrations starting with 11 ?
Alternatively assign a developer a number, 1, 2, 3, 4 etc and all the
migrations become 113_ if they are developer 3 or 114_ if they are
developer 4 etc.
It would be nice if there was a way to track all migrations individually
and somehow specify which are dependent on others…
Agreed.
Best Regards
Eaden McKee
Since there are now two 11 migrations, the migrate barfs and dies.
How about making migrate work with 2 migrations starting with 11 ?
Alternatively assign a developer a number, 1, 2, 3, 4 etc and all the
migrations become 113_ if they are developer 3 or 114_ if they are
developer 4 etc.
Don’t think this would work as once you rake/migrate to 114 it will
never
every run the 113 migration again…
On 6/28/06, Ryan P. [email protected] wrote:
workout just fine. But, after a checkout and a “rake migrate” a problem
developer. But, what I am curious about is how other people in similar
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
I think the best solution is the way you handle any checkin conflicts
- communication. Get svnnotify wired up, get on campfire/irc and feed
your svn notices there, and tell your developers to talk about their
migration plans.
Also, your developers should really do a svn up right before commit,
then run all test, and notice there that there is a problem with
duplication migrations before they every checkin.
I agree with the above statement. I work with multiple developers and
essentially we communicate constantly via IM and let each other know
when we create migrations so that we can do check-ins and then updates.
On Wed, Jun 28, 2006 at 05:06:17PM -0700, Ryan P. wrote:
We are both making migrations and checking them into SVN. So, if in our
checkout we have migrations up to 10 and we each make one, we both now have
the 11th migration. So, when we check-in, there are no problems and things
workout just fine. But, after a checkout and a “rake migrate” a problem
occurs. Since there are now two 11 migrations, the migrate barfs and dies.
My solutions so far look like this:
Pre-commit hook to check for uniqueness of migration version numbers
(maybe
5 lines of ruby, if that). IIRC, svn requires the tree to be up-to-date
before commit, so that should solve the entire problem.
Thanks to those who have replied, I appreciate it. I always like to hear
what others are doing to solve a problem and I’ll take your suggestions
into
my development cycle and hope that I can improve on the already existing
process.
Ryan
Hi Ryan,
Probably you need to improve your communication with your partner.
anyway you must be using IM’s.
the problem is not with rails, more with your development style.
for my projects, I would ask my team members to try/develop the
features/functionalities seperately based on tickets which have been
created.
and one tested thoroughly, they are added to core project, this way
extracting code is easier and over the time have build many reusable
components.
also we put our app on staging server on daily basis, for our management
and stakeholders to see and give feedback, we make weekly production
releases
regards
A.Senthil N.
http://senthilnayagam.com
2006/6/29, Matt P. [email protected]:
Pre-commit hook to check for uniqueness of migration version numbers (maybe
5 lines of ruby, if that). IIRC, svn requires the tree to be up-to-date
before commit, so that should solve the entire problem.
Unless you are committing tree deletions, property updates or changes
to an existing file that was changed before you committed, you can
have a non up-to-date working copy. But I agree the pre-commit hook
is a good idea. 5 lines ? Maybe a bit more though.
Bye,