scttnlsn
commented
11 years ago dandelion deploy <revision> will read the .revision file off of the server and determine what files differ between the server revision and the revision argument passed to dandelion deploy. Only those changes will be transferred to the server.
Dandelion takes the Git commit SHA stored in .revision (on the server) as the truth about the state of the files on the server. If you absolutely know the equivalent revision SHA of the files on the server you could always update the contents of .revision manually.
An example:
- Someone edits files directly on the server
- You pull them down to your local Git repo and commit any changes
- You assume that nobody has made changes on the server in the meantime
- Rather than deploying the changes you just downloaded, you edit the
.revisionfile to contain the SHA of your local HEAD revision.
Does that answer your questions?
mattfelten
This isn't an issue per say but I was looking for some explanation on how the revision system (
$ dandelion deploy <revision>) works. Does it only deploy the files changed in that specific commit or does it upload everything between the version Dandelion thinks the server is on and the revision?My example workflow is that on a couple of sites I manage, someone else makes code changes on the server. When I work on the site, I download the entire site locally, commit the new changes, then make my changes, commit and upload. I'd like to have a way to tell Dandelion what commit the server is on so I can just run a deploy for my changes. Does that make sense?