Hi Eric,

On Aug 27, 2010, at 3:40 AM, Eric Kow wrote:
> Hmm, let's see if we understand it the same way.  I was thinking quite
> simply in terms of the order that the patches appear in the repository.
> 
> Basically I was advocating that all patches common to repositories be
> in the same exact order everywhere. This is important because we can't
> guarantee that (A) converting commuted patches results in the patches
> you'd get by   (B) commuting converted patches. See what I mean?
> 
> I *think* I'm saying that
> 
>        (X Y <-> Y' X') 
> NOT => (cv(X) cv(Y) <-> cv(Y') cv(X'))
> 
> Where cv means 'convert', but there's a good chance of me being wrong.

This really clarifies things, and assuming I understand this explanation, it 
seems like our upgrade path is a safe one.  To detail it a little bit more:

1.  We have one darcs1 repository that all of our developers push to once the 
patches have been OK'd.  Let's call it "production.v1".
2.  We all maintain branches off of "production.v1" where we test our own 
additional bits of code before pushing back onto "production.v1".  Let's call 
the first "production-branch-1.v1", and the second "production-branch-2.v1".  
These two branches could have been get'd at different times, and therefore will 
likely have differing subsets of "production.v1".  It goes without saying that 
they have completely different supersets from "production.v1"
3.  Prior to the darcs upgrade, it's possible that either 
"production-branch-1.v1" or "production-branch-2.v1" may have pulled from 
"production.v1" to get additional patches which were committed to 
"production.v1" in the intervening time.  Since we haven't upgraded darcs yet, 
these commuted patches relative to each branch aren't a problem for darcs to 
deal with in the case that we want to push between the branches.

Upgrade from darcs1 to darcs2:
4.  Convert "production.v1".  Let's call it "production.v2"
5.  Convert branches.  They're temporary, let's call them 
"production-branch-1.v2_tmp", and the second "production-branch-2.v2_tmp"
6.  'Get' a copy of "production.v2" for each branch which we have.  Let's call 
them "production-branch-1.v2", and "production-branch-2.v2" 
7.  For each of the temporary branches from step 5, we do an email send to each 
of the corresponding production branches we've made in step 6. I'm not sure 
whether there's any functional difference between an email and a 'push', if 
there's not, just assume a push.
8.  At this point, both branches production-branch-1.v2", and 
"production-branch-2.v2" are both ordered the same in relation to one another.  
"production" is first, and all additional patches come after.
9.  Remove the temporary converted branches created in step 5, we're only to 
use the branches from step 6.

I realize this may not suit everyone's needs, and it may be flawed in the fact 
that there may have been commuted patches between the branch conversion 
relative to the production conversion, however in our case, darcs hasn't 
complained.  Our repository is medium-sized, with approximately 12k patches.  
I'm attaching a script which we used for the conversion in case all of this is 
not clear.  Who knows, it may help someone out there...

> 
>> In the case above (and in all of the cases which we try), all of the
>> patches in the branch will appear after (order-wise in the 'changes'
>> output) all of the main repo patches (iirc).  What situations would
>> not cause this "prefix" behavior?
> 
> So if you have your branch with main patches intermingled with common
> patches, converting that could have unpredictable results (maybe
> fine, but maybe broken)
> 
>  m1 m2 c1 c2 m3 m4 is BAD (because you don't know if the m3 and m4
>                            you get are really what you want)
>  m1 m2 m3 m4 c1 c2 is fine
> 
> Is that any clearer?

Much clearer, thank you.  Is there any way for us to test whether or not our 
conversion actually went ok?  Any way to know that several years down the road 
darcs just won't blow up on account of this form of upgrade?

Thanks,
-lev


Attachment: upgrade_darcs.sh
Description: Binary data

_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users

Reply via email to