init-wrap: new -Name input #157

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
@petejohanson
Contributor

petejohanson commented Feb 24, 2011

We use bzr for revision control, and very often use "feature branches" for doing our work. Since bzr uses separate directories for each branch, we often have a setup like:

  • my-project-repo
    • mainline
      • MyProject.wrapdesc
    • ftr_branch_one
      • MyProject.wrapdesc
    • ftr_branch_two
      • MyProject.wrapdesc

When we add a new .csproj to the solution, we of course need to update the project file to use the OpenWrap targets instead of the default ones. As far as I know, the only way to do that is with the "init-wrap" command. Unfortunately, init-wrap uses the directory name for the package name, so doing something like:

"ftr_branch_two> o init-wrap -All true -NoSymlinks true -IgnoreFileName .bzrignore"

Results in a new ftr_branch_two.wrapdesc file getting generated. This then causes headaches for MSBuild, etc, etc.

This branch adds a new -PackageName parameter to init-wrap, so we can instead do:

"ftr_branch_two> o init-wrap -PackageName MyProject -All true -NoSymlinks true -IgnoreFileName .bzrignore"

And it detects the existing MyProject.wrapdesc and behaves as expected.

Thoughts? Suggestions on a better way to handle this?

@serialseb

This comment has been minimized.

Show comment Hide comment
@serialseb

serialseb Mar 2, 2011

Let me check if I understand the scenario.
init-wrap Target
Creates a Target project in a newly created Target folder

init-wrap Target Name
Creates a Name project in a newly created Target folder

init-wrap . Name
Creates (if needed) a Name project in the current folder

If that's the case, pacakge name should still default to the existing values or you'd end up breaking some of those scenarios. I'd also prefer if it was called Name, as there's plenty of projects that need to be created that do not end up being a package (although it'd of course be much better if everything was a pacakge :) )

Let me check if I understand the scenario.
init-wrap Target
Creates a Target project in a newly created Target folder

init-wrap Target Name
Creates a Name project in a newly created Target folder

init-wrap . Name
Creates (if needed) a Name project in the current folder

If that's the case, pacakge name should still default to the existing values or you'd end up breaking some of those scenarios. I'd also prefer if it was called Name, as there's plenty of projects that need to be created that do not end up being a package (although it'd of course be much better if everything was a pacakge :) )

This comment has been minimized.

Show comment Hide comment
@petejohanson

petejohanson Mar 2, 2011

Owner

Yes, those are the the scenarios. I can easily rename the parameter to "Name" instead. If you check out the PackageName property, it does replicate the existing "default values" if the parameter isn't explicitly specified. Is that what you meant by "still default to the existing values" ?

Owner

petejohanson replied Mar 2, 2011

Yes, those are the the scenarios. I can easily rename the parameter to "Name" instead. If you check out the PackageName property, it does replicate the existing "default values" if the parameter isn't explicitly specified. Is that what you meant by "still default to the existing values" ?

This comment has been minimized.

Show comment Hide comment
@serialseb

serialseb Mar 2, 2011

Ah, yes, of course, it makes sense. If you rename that to Name then I can pull :)

Ah, yes, of course, it makes sense. If you rename that to Name then I can pull :)

This comment has been minimized.

Show comment Hide comment
@petejohanson

petejohanson Mar 2, 2011

Owner

Updated. See my pull request.

Owner

petejohanson replied Mar 2, 2011

Updated. See my pull request.

@ghost ghost assigned serialseb Jun 12, 2011

serialseb added a commit that referenced this pull request Jun 13, 2011

@serialseb

This comment has been minimized.

Show comment Hide comment
@serialseb

serialseb Jun 16, 2011

Member

Done and dusted.

Member

serialseb commented Jun 16, 2011

Done and dusted.

@serialseb serialseb closed this Jun 16, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment