[darcs-users] is this a legitimate way to convert from v1 to v2?

Lev Lvovsky lists2 at sonous.com
Fri Aug 27 17:25:05 UTC 2010


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: upgrade_darcs.sh
Type: application/octet-stream
Size: 2154 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100827/7ba70af3/attachment.obj>


More information about the darcs-users mailing list