This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.
Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.
Before posting questions here you might want to review the developer documentation.
Hi Joe,
Just a quick request.
Would it be possible for you to create a global tag your on your "release" changesets in Mercurial. It does not look like the "Associated with release" tag created in CodePlex makes it way into the repository.
Just saves having to go onto CodePlex to check (I can do this from repository explorer).
Also, I've created a blog post about how I set up my mojoPortal environments including merging in changes from the codeplex repository. I thought it might help others - http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Setting-up-a-mojoPortal-development-environment.aspx
Cheers,
Ben
I made a branch for 2.3.4.5 that has no new changes vs the changeset.
Good blog post!
Best,
Joe
I was going to suggest that you employ tags rather than branches for labeling release versions. Mercurial named branches are intended for separate lines of development and carry the weight that goes with that (new heads, need for merging to bring code across to the normal line of development, a permanent entry in the branch list).
Tags are more appropriate when you aren't intending to branch the code off at that point. As it is difficult to develop for mojoPortal without making some minor changes to the source files which are under version control, I'd like to commit my small changes but have them follow your line of development. I'm trying to do this by setting my working copy to a released version and then updating only when I'm ready to handle a new released version (I only develop off of releases). The rebase command can work with this, moving my commits after yours each time I update, however I've already encountered the gotcha that the branch name branches off a new line when I updated to your last release. My commit is now on its own branch and therefore must be merged if I want to bring it to your next release.
Hence the suggestion. Not only are tags intended for what you are doing, they make reapplying my minor commits after your latest changes trivial with the rebase command.