A friend recently had the occasion for a legal name change, which made me wonder about how to cope with that in a development environment, especially in regards to source control.
Their legal name changed, so naturally their login name and associated identity stuff changed. If they were a team member of mine, I'd like to change the record of their past commits to the project to be consistent with their new name. Is that possible in Mercurial? In other version control systems?
See the ConvertExtension. It can be used to do a Mercurial-to-Mercurial database conversion. Specifically, see the --authors switch to remap author names.
Related
I am trying to learn about git/GitHub workflow. I'm on branches, and learning about the different typical branch name prefixes. I've read several of the key articles.
If I name a branch issue-*, you can correspond that to an existing issue in the GitHub issue tracker by adding its number, like issue-32, is that right?
Is this number only for the developer's own tracking, or does it actually get associated with the issue, such that the branch somehow appears linked on the issue?
If a topic branch named like issue-32 does form an association with the issue, would other conceivable topic group prefixes do the same? Ie. If you were storing a feature note as issue 76, does branch feature-something-76 make any association with it?
Thinking it through, am I wrong to think that a branch could be associated with an issue? Is it, rather, that you associate commits with issues? And, if that's the case for issue-*, it's also the case for feature-*?
Ie. Should I only ever be referencing issue numbers in a commit message, eg. "Fixes issue #32" (and is there any particular nomenclature required beside use of the integer?)?
This answer shows GitHub, only a few weeks ago, introduced a new feature to create a new branch from an existing issue. But that's a) the other way around from my question and b) from the web (not sure how I'd do this in VS Code). Also seems like the linkage only happens upon a pull request.
I once ran across a commercial tool for Windows that allowed you to "stash" code changes outside of source control but now I can't remember the name of it. It would copy the current version of a document to a backup location and undo your checkout in source control. You could then reintroduce your backed up changes later. I believe it worked with multiple source control systems. Does anyone know what program I'm trying to describe?
The purpose of my asking is twofold: The first is to find a good way to do this. The second is because I just can't remember what that darn program was and it's driving me crazy.
Git: http://git-scm.com/
You can use git stash to temporarily put away your current set of changes: http://git-scm.com/docs/git-stash . This stores your changes locally (without committing them), and lets you reintroduce them into your working copy later.
Git isn't commercial, but is quickly gaining many converts from tools like Subversion.
I think the product you're thinking of is "CodePickle" by SmartBear Software. However, it appears to be a discontinued product.
The term that seems to be used for the type of functionality you're looking for seems to be 'shelving'.
Microsoft's Team system has a 'shelve' feature.
Perforce has several unsupported scripts, including p4tar and p4 shelve
There are several 'shelving' tools for Subversion, but I don't know how robust they are.
I'm no git user myself, but several of my colleagues are, and they seem to like it precisely for this purpose. They use the various git wrappers to commit "real" changes to the SCM system used by their company, but keep private git repositories on their drives which they can keep their changes which they don't necessarily want to commit.
When they're ready to commit to the company's SCM server, then they just merge and commit upstream. Is that what you're looking to do?
Wouldn't it be a better idea to store your private changes in private branch, using e.g. svn switch to change to main branch whenever you need to?
Mercurial has the Shelve Extension which does what you want.
You can even select which changes from a single file that you want to shelve if you really want.
In Darcs, you either don't record the changes you want stashed (it asks you about including each change independently when you record a new patch), or put them in separate patches that you don't push upstream.
There's no need to fully synchronize your local private repos with public/upstream/other ones. You can just cherry pick the patches you want to push elsewhere. Selecting patches can also be done with patterns, so if you adopt a naming convention for your stashed patches you can push everything but them easily.
That way, your private changes are still in revision control, but they aren't shared until you want them to be.
I found an excellent article about obtaining similar functionality using Subversion branches:
Shelves-in-subversion
And then there's the old fallback... 'patch', or even the old "copy everything to another location, then revert".
Both of these are less convenient than using tools that are part of most VCS systems, though.
My boss announced yesterday a new commit policies for checkins into the repository. This policies are valid for commits into head/trunk and branches.
A commit message must have the following items:
Reason (Bug ID,Project ID, or non functional change)
Name of the reviewer
After the commit we also have to create a change blog entry in our CMS.
I'm not a big fan of this commit policies, because I don't normally need a reviewer when I am doing new or experimental stuff in a non-productive-branch.
Do you have any commit policies do you have to follow?
I think it is a good idea to change the productive-branch only due to a Bug Report, but commits into the development branches should be less restrictive.
Commit early and commit often.
We actually use /trunk as development and tags to branch different releases. Only structural intrusive changes go in /branches.
We actively use tags for production and acceptation releases, so we can go back in time easily. Anything committed in the trunk should only have a message describing what the commit changed or added briefly.
I'm not a big fan of using the message space to link with Bug ID's it still requires a lookup for the ID in which case you could also look it up in the bug tracking software and close it there, which to me is about the same effort.
Not to say i dont like any svn integration:
- We use more goodness of automated nant scripts to make releases which branches them in /tags
- svn props actually store our version numbers :p.
- hook scripts for email notification and message logging (great for copy pasting release notes).
We have a number of policies, which are enforced via an in-house plug-in to Visual Studio. We check that code compiles and that unit tests have be run successfully. At the moment we also check code coverage and issue warnings for code which doesn't have enough tests. We also do various consistency checks and verify that an appropriate task is present in our change management system in order to provide traceability for all changes.
The advantage of tool support is great, as it is not really up to people to respect the policies, but obviously there's a drawback as well as these checks take time to run. However, with many developers it is hard to enforce standards without proper tool support.
A reviewer seems pointless for the reasons you mentioned, because not everything needs to be reviewed by others.
In the past the only commit policy we had (where I used to work) was to include a comment indicating what you changed and why, but that's more common sense than anything else.
A common commit policy is to associate a bug ID to the commit to trunk as a justification. Sometimes, version control and bug tracking systems are configured to enforce this policy.
Our commit policy sounds a bit like yours, only we don't enforce it on task branches (where a task branch is like a developer's sandbox for experimenting).
Our commit comments must include either a change control ID (new feature, enhancement) or an issue ID (bug fix). You must also include a brief explanation as to why you made this change; version control tracks the who, what, when and where.
My commit message include a short describtion what i have implemented or changed in the classes.
The bug number and additional describtions i put in the commentation above the new code. IDs inside the commit messages we put when we merge changes into a tagged branche.
Every night a automatic build checks the different features and products too get sure that the code base is stabil.
But in the end i think you can not have too many describtions for new or changed classes but too many policies you have to do before a commit. The name of the reviewer is something which i would not put into the commit message.
Think about that you sometimes have to undestand your code which you have implemented 2 years ago. And then you are happy about commit messages which are not like "Update after debugging".
We have branches for every released major version of the software that is still actively supported. Checking into any of these branches requires a bug ID - this is enforced by scmbug, which will not only check that the comment is prefixed by the bug ID, but will also look up this bug in the bug database, ensure it is assigned to the committer, and potentially check other criteria (e.g. that the "fix in branch" field is the branch being committed to).
One of the products has more potential to fail in embarrasing ways, and checkins to this require not just a bug ID but a code review as well. However, the criteria for the code reviewing is handled in our bug database - we have custom fields for this and the bug cannot be accepted and closed until it has been reviewed. To me this works from a conceptual level - it's probably better to check code that is believed to work into the repository un-reviewed, then reopen the bug and change it if necessary rather than hold off on committing until you're sure it is ready for release.
Other than that, there's no explicit policy for the trunk (though of course the general tenets of checking in often without breaking the build, including good descriptive commit messages, checking in units of work atomically still apply).
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.
I've tried using source control for a couple projects but still don't really understand it. For these projects, we've used TortoiseSVN and have only had one line of revisions. (No trunk, branch, or any of that.) If there is a recommended way to set up source control systems, what are they? What are the reasons and benifits for setting it up that way? What is the underlying differences between the workings of a centralized and distributed source control system?
Think of source control as a giant "Undo" button for your source code. Every time you check in, you're adding a point to which you can roll back. Even if you don't use branching/merging, this feature alone can be very valuable.
Additionally, by having one 'authoritative' version of the source control, it becomes much easier to back up.
Centralized vs. distributed... the difference is really that in distributed, there isn't necessarily one 'authoritative' version of the source control, although in practice people usually still do have the master tree.
The big advantage to distributed source control is two-fold:
When you use distributed source control, you have the whole source tree on your local machine. You can commit, create branches, and work pretty much as though you were all alone, and then when you're ready to push up your changes, you can promote them from your machine to the master copy. If you're working "offline" a lot, this can be a huge benefit.
You don't have to ask anybody's permission to become a distributor of the source control. If person A is running the project, but person B and C want to make changes, and share those changes with each other, it becomes much easier with distributed source control.
I recommend checking out the following from Eric Sink:
http://www.ericsink.com/scm/source_control.html
Having some sort of revision control system in place is probably the most important tool a programmer has for reviewing code changes and understanding who did what to whom. Even for single person projects, it is invaluable to be able to diff current code against previous known working version to understand what might have gone wrong due to a change.
Here are two articles that are very helpful for understanding the basics. Beyond being informative, Sink's company sells a great source control product called Vault that is free for single users (I am not affiliated in any way with that company).
http://www.ericsink.com/scm/source_control.html
http://betterexplained.com/articles/a-visual-guide-to-version-control/
Vault info at www.vault.com.
Even if you don't branch, you may find it useful to use tags to mark releases.
Imagine that you rolled out a new version of your software yesterday and have started making major changes for the next version. A user calls you to report a serious bug in yesterday's release. You can't just fix it and copy over the changes from your development trunk because the changes you've just made the whole thing unstable.
If you had tagged the release, you could check out a working copy of it and use it to fix the bug.
Then, you might choose to create a branch at the tag and check the bug fix into it. That way, you can fix more bugs on that release while you continue to upgrade the trunk. You can also merge those fixes into the trunk so that they'll be present in the next release.
The common standard for setting up Subversion is to have three folders under the root of your repository: trunk, branches and tags. The trunk folder holds your current "main" line of development. For many shops and situations, this is all they ever use... just a single working repository of code.
The tags folder takes it one step further and allows you to "checkpoint" your code at certain points in time. For example, when you release a new build or sometimes even when you simply make a new build, you "tag" a copy into this folder. This just allows you to know exactly what your code looked like at that point in time.
The branches folder holds different kinds of branches that you might need in special situations. Sometimes a branch is a place to work on experimental feature or features that might take a long time to get stable (therefore you don't want to introduce them into your main line just yet). Other times, a branch might represent the "production" copy of your code which can be edited and deployed independently from your main line of code which contains changes intended for a future release.
Anyway, this is just one aspect of how to set up your system, but I think giving some thought to this structure is important.