Bugzilla – Bug 1671
bake not updating existing source directory for upstream changes
Last modified: 2013-09-06 04:27:43 UTC
In testing bake changeset 251:30dd1eca8732 on Ubuntu 13.04, for ns-3.17 module, I noticed that 'bake.py download' was not updating the existing ns-3.17 (ns-3-dev) source directory. That is, if there is an existing source/ns-3.17 directory, and the upstream repository changes, bake is not pulling these updates. ./bake.py download -vvv yields: >> Downloading ns-3.17 - >> Download ns-3.17 - OK but after cd'ing into source/ns-3.17, 'hg tip' yields: changeset: 9736:da5e3a6c4029 however, ns-3-dev is actually on changeset 9739 211496d6d5d6
This is intentional to avoid the user to lose any changes made in the sources of the module. If the user is working on the module an update or a clone could make him waist all his job. By default, if the directory exists bake does not download it again. The action users are supposed to perform is either to remove the directory, and download it again, or call bake update. Maybe it should be more clear in the documentation, but I would also say the bug is invalid... or at least it is reporting something that was planned to be this way... if you want a change... it can be done.... but I guess this could be dangerous for the user, I think a more conscious action would be important in this case.
(In reply to comment #1) > This is intentional to avoid the user to lose any changes made in the sources > of the module. If the user is working on the module an update or a clone could > make him waist all his job. By default, if the directory exists bake does not > download it again. > > The action users are supposed to perform is either to remove the directory, > and download it again, or call bake update. Maybe it should be more clear in > the documentation, but I would also say the bug is invalid... or at least it is > reporting something that was planned to be this way... if you want a change... > it can be done.... but I guess this could be dangerous for the user, I think a > more conscious action would be important in this case. OK, I wasn't aware or had forgotten about the update vs download distinction. Maybe this could raise a warning, however, that downloading was suppressed because it found a pre-existing directory. The existing output might surprise others besides me. I guess I'll leave it open rather than mark as invalid just yet, for this point.
Fixed at changeset 276. Now a message is printed to the user so that he is aware that the download didn't grab the sources, since they are already present in the sources directory. If bake is called in verbose mode (-v, -vv or -vvv) a more verbose message is presented giving the user the options to remove the module from the source directory, use --force_download or call bake update.