You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Leonard <jl...@gmx.com> on 2012/02/20 01:34:09 UTC

Keep separate checkouts up to date

What is a good way to keep multiple checkouts up to date? Would it be to  
first, commit each one then update each one?

John L.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Keep separate checkouts up to date

Posted by Les Mikesell <le...@gmail.com>.
On Mon, Feb 20, 2012 at 8:31 AM, Ulrich Eckhardt <
ulrich.eckhardt@dominolaser.com> wrote:


> I'd generally update regularly, more than once a day even. However, when
> I'm in the middle of working on something, I don't want other people's
> changes to come in, so I defer updating. Before committing though, I must
> make sure that my changes don't conflict, so I have to update first, then
> test again, then commit.
>
> That said, committing at the end of a work day (I'm not sure if that is
> what you meant) is a bad idea, as it conveys zero useful information. If
> you are concerned about data loss, then you need a backup solution in
> addition.
>

Again, depending on the relationship of the changes being done
concurrently, you can separate the effects of committing and sharing the
changes with branching.  That is, you can make a branch for each workspace
to check out separately so they can commit anything or any time they want
without the changes being picked up by the others, and then the work can be
merged when the changes are complete.   Look for descriptions of the
'feature branch' style of working. Personally, I think it is usually better
to do new development on the trunk to take advantage of each others' work
and fix conflicts sooner rather than later, but it really depends on the
nature of the work.   Also, if the work has 'release' points with
feature-freezes and stability testing, look at the 'release branch' style
that lets more drastic changes continue on the trunk after you make the
initial release cut.

-- 
  Les Mikesell
    lesmikesell@gmail.com

Re: Keep separate checkouts up to date

Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 20.02.2012 03:07, schrieb John Leonard:
> So one strategy would be, say, to perform an update at the beginning of
> a workday at each workstation and then commit at the end of work?

I'd generally update regularly, more than once a day even. However, when 
I'm in the middle of working on something, I don't want other people's 
changes to come in, so I defer updating. Before committing though, I 
must make sure that my changes don't conflict, so I have to update 
first, then test again, then commit.

That said, committing at the end of a work day (I'm not sure if that is 
what you meant) is a bad idea, as it conveys zero useful information. If 
you are concerned about data loss, then you need a backup solution in 
addition.

Committing blindly might even commit half-complete changes. Instead, if 
you have completed a change, commit that. Don't accumulate changes for a 
day (let alone longer!) and don't commit unrelated changes in one 
checkin. This makes it clearer to you and others what you did and why, 
and it makes it possible to pinpoint when something broke to a single 
revision. If you check in every evening, there might be a lot of changes 
to hunt bugs in. There might even be changes that cause the whole thing 
to break because they are incomplete, so two revisions where things are 
in a sane state might be more than one day away from each other.

Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************


Re: Keep separate checkouts up to date

Posted by Les Mikesell <le...@gmail.com>.
On Sun, Feb 19, 2012 at 8:07 PM, John Leonard <jl...@gmx.com> wrote:

> first, commit each one then update each one?
>>>
>>>
>>>  Yes, normally these events are not strictly synchronized.   Commit when
>> you
>> are sure a set of changes are in a state you want to save, and update when
>> you are ready to pick up the changes from others.   But the longer you
>> delay, the more likely it becomes to have conflicting changes.
>>
>> What is a good way to keep multiple checkouts up to date? Would it be to
>
> So one strategy would be, say, to perform an update at the beginning of a
> workday at each workstation and then commit at the end of work?
>
>
It really depends on how the changes relate to each other.  With source
code you might want to do a test compile to make sure a set of changes
don't break things before the commit.  And if one set of changes can take
advantage of another or are likely to have conflicting duplicate changes,
you might do it more often.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Keep separate checkouts up to date

Posted by John Leonard <jl...@gmx.com>.
On Sun, 19 Feb 2012 20:12:31 -0500, Les Mikesell <le...@gmail.com>  
wrote:

> On Sun, Feb 19, 2012 at 6:34 PM, John Leonard <jl...@gmx.com>  
> wrote:
>
>> What is a good way to keep multiple checkouts up to date? Would it be to
>> first, commit each one then update each one?
>>
>>
> Yes, normally these events are not strictly synchronized.   Commit when  
> you
> are sure a set of changes are in a state you want to save, and update  
> when
> you are ready to pick up the changes from others.   But the longer you
> delay, the more likely it becomes to have conflicting changes.
>

So one strategy would be, say, to perform an update at the beginning of a  
workday at each workstation and then commit at the end of work?

John L.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Keep separate checkouts up to date

Posted by Les Mikesell <le...@gmail.com>.
On Sun, Feb 19, 2012 at 6:34 PM, John Leonard <jl...@gmx.com> wrote:

> What is a good way to keep multiple checkouts up to date? Would it be to
> first, commit each one then update each one?
>
>
Yes, normally these events are not strictly synchronized.   Commit when you
are sure a set of changes are in a state you want to save, and update when
you are ready to pick up the changes from others.   But the longer you
delay, the more likely it becomes to have conflicting changes.

-- 
  Les Mikesell
    lesmikesell@gmail.com