Rails - Jun 2006 - Handling multiple developers making migrations and using svn

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:


   1. Manually make sure that the migrations are numbered in numerical
   order
   2. 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
   3. 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

-- 
Ryan Prins
rprins@gmail.com
http://www.lazyi.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060629/c6c78972/attachment.html

> 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:
>
>
>  1. Manually make sure that the migrations are numbered in numerical
>  order
>  2. 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
>  3. 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?
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
-- 
Webforce Ltd | www.webforce.co.nz

>> >  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....
>
>>> 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
> -- 
> Webforce Ltd | www.webforce.co.nz
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 6/28/06, Ryan Prins <rprins@gmail.com> wrote:
> 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 dateThe 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
>
> --
> Ryan Prins
> rprins@gmail.com
> http://www.lazyi.net
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> 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.

- Rob
-- 
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.com

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

On 6/28/06, Rob Sanheim <rsanheim@gmail.com>
wrote:
>
> On 6/28/06, Ryan Prins <rprins@gmail.com> wrote:
> > 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 dateThe 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
> >
> > --
> > Ryan Prins
> > rprins@gmail.com
> > http://www.lazyi.net
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > 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.
>
> - Rob
> --
> http://www.robsanheim.com
> http://www.seekingalpha.com
> http://www.ajaxian.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
Ryan Prins
rprins@gmail.com
http://www.lazyi.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060629/e90d6ae8/attachment.html

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.

- Robert Dempsey
  http://www.techcfl.com

-- 
Posted via http://www.ruby-forum.com/.

On Wed, Jun 28, 2006 at 05:06:17PM -0700, Ryan Prins
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.

- Matt

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 Nayagam
http://senthilnayagam.com


-- 
Posted via http://www.ruby-forum.com/.

2006/6/29, Matt Palmer <mpalmer@hezmatt.org>:
> 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,
-- 
Fran?ois Beausoleil
http://blog.teksol.info/