Switching Branches (Git) leaves .wrap files
Closed this issue · 12 comments
I have a master branch using a fixed set of versioned wraps and a support branch that uses a fixed set of older versioned wraps.
When I checkout my support branch, .wrap files are left in my wraps directory that are later than the fixed versions(!). This means that when I then come to do an "o update-wrap", the world ends and wraps update, despite versions being anchored.
Let me make sure I understand this correctly.
Git checkout master
/wraps/openwrap-2.0.0.wrap
Git checkout old
/wraps/openwrap-1.0.0.wrap
Are you saying that when you checkout the second branch, the .wrap file stays behind?
-----Original Message-----
From: Lee Crossley [mailto:reply@reply.github.com]
Sent: 03 October 2011 12:23
To: Sebastien Lambla
Subject: [openwrap] Switching Branches (Git) leaves .wrap files (#256)
I have a master branch using a fixed set of versioned wraps and a support branch that uses a fixed set of older versioned wraps.
When I checkout my support branch, .wrap files are left in my wraps directory that are later than the fixed versions(!). This means that when I then come to do an "o update-wrap", the world ends and wraps update, despite versions being anchored.
Reply to this email directly or view it on GitHub:
#256
I've repeated the process a couple of times and I think the problem is slightly different to what I described. When I do an "o update-wrap" later versions of the wraps are downloaded (expected). When I then do an "o clean-wrap" the anchored versions are removed and the later versions are kept. I am now assuming that this is due to a wrap referencing a version of another wrap higher than the anchored version. Does this ever get logged/reported anywhere?
When you do a clean-wrap, only the latest version in use is kept, the others are deleted. This does not impact anchored packages, those would've been changed when you did the update to start with, unless you had a bunch of locks on some of those files (say, VS or notepad or whatever). We report it by warning you that packages cannot be anchored due to file locks.
Note that 2.0 is going to provide a new way to link to builds, so the anchored feature won't be used for VS anymore, and should solve those file lock issues fairly quickly.
We're currently using version 2 of OpenWrap (should have mentioned this). To anchor versions we're doing: "depends: RavenDb-Embedded = 1.0.0.427" in the .wrapdesc but these don't seem to be adhered to.
It's updating to the latest version of RavenDb and then removing .427 when cleaning wraps
I think we're not talkign about the same thing here. Anchoring of packages is what is described in https://github.com/openrasta/openwrap/wiki/Package-anchoring. What exactly are you talking about?
Also note that you cannot take a dependency on an updated revision number, those are ignored by OpenWrap as they're suppopsed to only be used for patches that can auto-update. If a library author is using the revision to mean something else, point them to semver.org and try to lobby them to adopt a more rational versioning scheme. :)
We're "fixing" versions of wraps:
.wrapdesc contains: "depends: RavenDb-Embedded = 1.0.0.427"
o update-wrap: downloads RavenDb-Embedded 1.0.0.482 <-- This is strange
o clean-wrap: removes RavenDb-Embedded 1.0.0.427 <-- This is not expected, as I have fixed to version 1.0.0.427
See above and https://github.com/openrasta/openwrap/wiki/Package-versioning. This is completely expected behavior. What's not expected is for Raven to push an incompatible version as a new revision of their package if they have breaking changes between packages, and they should address that problem. You cannot take a dependency on a revision number in OpenWrap because it's a piss-poor practice to hide away breaking changes without semantically advertising the fact, and library authors should start understanding version management. There will be an upcoming "dev-time" locking of package versions in OpenWrap, but that's not implemented yet and may not be for beta 1.
I'm afraid at this stage the only solution is to either: not update ravendb (do an update-wrap on other packages), not pull from nuget on updates and use your own repository of "vetted" pacakges (you just need someone to pull the package from nuget and push it to your openwrap repository), or to have your own package with your own build of ravendb, name it differently (Custom-RavenDb) and use the override functionality to pull that package in-lieu of raven.
I've filled an issue with ravendb/ravendb#382 to try and get them to address the problem on their side.
Hi Seb,
I can see what you are saying but we are in a situation where we have frozen a build (post release) and are attempting to continue to support this while adding new wraps.
If we have specified that we do not want to upgrade past a certain version (independent of any mistakes that our sources may have made) then the version control system should listen to the input from the user (our wrapdesc specifying a version) and not upgrade and ignore our instructions.
Cheers
Andrew
I certainly understand your problem. Allowing revision-builds breaks a bunch of core scenarios that we wanted to support with OpenWrap. Locking will solve the problem you have without resorting to enforcing dependencies that ought to not be taken and would break hot-patching. There is a fundamental difference between advertised compatibility between packages (and we enforce semver.org there, nuget doesn't and that's what the problem is) and development/production time stability (and this is what we're solving with locking). Mixing the two together is a foolish thing to do.
Allowing dependencies on revision would be the wrong thing to do, both from an engineering POV and for the ecosystem. If it's blocking for you I can prioritize locking work this week and introduce that feature earlier than planned. In the meantime, the workarounds provided ought to solve your problem for now. Alternatively, simply do not update the ravendb package.
I'm closing this issue for now as it is expected behavior. If you require assistance further, don't hesitate to reopen.