If I leave out a file when checking in, or accidentally include a file I don't want in a check in, is there a way to modify the changeset that was created?
You can modify a changeset's description and associated work items.
But there is no way to change the set of file changes (if it were possible then it would break atomicity—condsider what would happen if there had been another change to the file between the original, incomplete, changeset and now).
Check the file in separately with a mea culpa description: mistakes happen, most of good development practice is to deal with that reality.
Related
I know about templates. I know this has been asked before (here and here). Please let me explain my situation in detail and hopefully you'll understand why I'm asking this question again.
I use an IDE (and language) called PowerBuilder. PowerBuilder (PB) stores source code and binary object code together in a PBL (pibble) file. A PBL can contain source code for multiple classes. Because of this, it's not really practical to keep the PBL under version control; it's each individual class that should be revisioned independently. However, since it's the PBL file itself that the IDE uses, and because of the presence of the object code within the PBL, these files need to be pushed out when a repository is cloned. I can go into more detail on this if requested.
The PB IDE provides hooks for the MSSCCAPI interface so that it can support source code control providers. It works great with Visual Source Safe 6! But there are no usable MSSCCAPI providers for Mercurial. (I've asked before.) Yes, I'm trying to get the people that create PB to support an updated API, but there's no telling how long that will take. The IDE does, however, offer its own, basic, SCC functions. It's not a "real" solution; it's more of a "this will get you by, you cheap b*****d, until you can buy a real SCC program" type of thing. It works, though, by exporting the source for each class into individual text files and creating a corresponding "status" file (PRP file) for each class. Text files? Those can be tracked by Mercurial! FYI, this basic, "get you by" SCC option doesn't keep history or handle merges.
Let me detail a little more about these PRP files. PB's built-in SCC solution is built around exclusive locks. Check-out, check-in, all that old stuff. It manages these check-outs and check-ins via the PRP files. It also knows what is and what isn't under revision control by the presence of the corresponding PRP file.
So first with the PRP files. I need to have these pushed out (and added for new classes) so that the IDE can see that the corresponding class should be tracked. If there's no PRP file, the IDE doesn't export the syntax and nothing can get tracked in Mercurial. But if I continue to track changes to the PRP files, then that means that I'm pushing out the exclusive locks on the classes as well, and nobody wants that. So I need to add the PRP files but not track any subsequent changes to them.
And I need the same for the binary PBL files. As mentioned before, I need them to exist so that the IDE knows what PBLs make up a code base, but the complexities of the object code, compilation, and class inter-dependencies mean that it's not feasible to recreate them on the fly. So I need the PBLs added to Mercurial, but I don't really want to track the changes to those PBLs. And though I might be able to get by with templates for the PRP files, I can't do that for these binary PBL files.
Hopefully, that explains my situation fully. I apologize that this question is so long, but I wanted to make sure that you had a clear understanding of what I was up against so that I didn't get a bunch of off-the-cuff "This is a duplicate of X" responses. Thank you for your patience and for any guidance you can offer.
Even if I can't understand this
if I continue to track changes to the PRP files, then that means that I'm pushing out the exclusive locks on the classes as well, and nobody wants that. So I need to add the PRP files but not track any subsequent changes to them.
namely: "...nobody wants that..." and "...add the PRP files but not track any subsequent changes to them..." - if you don't version-contol changeable (and changed) sources I can't see reason to add outdated after fist change files to Mercurial
You can add, store and ignore later files in Mercurial. This answer play game nicely with small change: because you want .hgignore full working copy (really want?) you can use hg up -r N
Alternative solutions
SourceControl integration for PB 11.5 - TortoiseSVN (SVN)
WizSource - SCM on top of RDBMS
PushOk Git or SVN SCC plug-ins - Git or SVN respectively
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Before you start admonishing me with "DON'T DO IT," "BAD PRACTICE!" and "Learn to use proper source code control", please hear me out first. I am fully aware that the practice of commenting out old code and leaving it there forever is very bad and I hate such practice myself.
But here's the situation I'm in. A few months ago I joined a company as software developer. I had worked in the company for few months as an intern, about a year before joining recently. Our company uses source code version control (CVS) but not properly.
Here's what happened both in my internship and my current permanent position. Each time I was assigned to work on a project (legacy, about 8-10 years old). Instead of creating a CVS account and letting me check out code and check in changes, a senior colleague exported the code from CVS, zipped it up and passed it to me.
While this colleague checks in all changes in bulk every few weeks, our usual practice is to do fine-grained versioning in the actual source code itself (each file increments in versions independent from the rest). Whenever a change is made to a file, old code is commented out, new code entered below it, and this whole section is marked with a version number. A note about the changes is placed at the top of the file in a section called Modification History. Finally the changed files are placed in a shared folder, ready and waiting for the bulk check-in.
/*
* Copyright notice blah blah
* Some details about file (project name, file name etc)
* Modification History:
* Date Version Modified By Description
* 2012-10-15 1.0 Joey Initial creation
* 2012-10-22 1.1 Chandler Replaced old code with new code
*/
code ....
//v1.1 start
//old code
new code
//v1.1 end
code ....
Now the problem is this. In the project I'm working on, I needed to copy some new source code files from another project (new in the sense that they didn't exist in destination project before). These files have a lot of historical commented out code and comment-based versioning including usually long or very long Modification History section.
Since the files are new to this project I decided to clean them up and remove unnecessary code including historical code, and start fresh at version 1.0. (I still have to continue the practice of comment-based versioning despite hating it. And don't ask why not start at version 0.1...) I have done similar something during my internship and no one said anything. My supervisor has seen the work a few times and didn't say I shouldn't do such clean-up (if at all it was noticed).
But a same-level colleague saw this and said it's not recommended as it may cause downtime in the future and increase maintenance costs. An example is when changes are made in another project on the original files and these changes need to be propagated to this project. With code files drastically different, it could cause confusion to another developer doing the propagation. It makes sense to me, and is a valid point. I couldn't find any reason to do my clean-up other than the inconvenience of a ridiculously messy code.
So, long story short: Given the practice in our company, should I not do such clean-up when copying new files from project to project? Is it better to make changes on the (copy of) original code with full history in comments? Or what justification can I give for doing the clean-up?
PS to mods: Hope you allow this question some time even if for any reason you determine it to be unfit in SO. I apologize in advance if anything is inappropriate including tags.
If copy of some file from another project really means (for this sources) "The point of divergence" and parallel independent evolution of source and fork, than legacy history and commented code are effectively "white noise" and can be easy eliminated on your side. For future possible propagation from parent mentioning of "bifurcation point" only will be sufficient in first line of Modification History, smth. like
...
* Date Version Modified By Description
* 2012-10-25 1.0 ADTC Created from 12.34 of <filename>
...
Addendum by asker (ADTC):
I wish to quote a comment in addition to the answer above.
[...] take the source code, remove the comments related to who did what (history comments), but retain the comment regarding what the source code/class/method does (informational comments). That is what the comment section is supposed to be. It should clearly define what the method is doing, how it is implemented and under what condition an exception will be thrown. – Wins, 2012-10-25 00:57:57Z
If I am I going your position, I'd prefer to modify the other source code and make it as library to be used within my project.
I suggest using some version control yourself - I recommend git. Have one branch for "upstream" code that is synchronized with whatever you senior colleague currently has. Then you can have one or more branches for your work. You will have good overview what changes you made using git diff against "upstream" branch, you can search history of everything you ever did on that project etc. And this all is automatic, without manual code versioning, the files are always "clean", with all their history available in git.
Help me do some damage! I'm tired of just a half-dozen Google hits that tell me never to do this. Let's muck things up real good! I'm pretty sure that I can get ahold of the actual files in db/transactions, so how can I screw these up in interesting ways? I've looked at SVN::Delta, but I can't even figure out what it's supposed to be doing (letting someone make pretty graphs of changes to a repository? sending coded messages to the CIA?).
I really don't care to hear more reasons why not to do this. I work in an environment with 40 or 50 other people who use subversion. And while we're coding, we need some passwords in web.config files, in DataSource.groovy files, you name it. And just refusing the commit because we left them in is as annoying as hell. We have to save the files with the passwords manually deleted (and we have to open up those files, it's not like they're necessarily open), then once we're done committing we have to put them back just to continue to work? This is a good idea I suppose if you just want to bitchslap people every time they commit until they develop a Pavlovian reflex to never commit anything. And why? Because computers aren't supposed to automate tasks? Because the software client won't know that the pre-commit hook didn't actually save the version still on the developer's machine?
I'm fairly language agnostic here. Show me an example of how to do what you're never supposed to do... which file do I edit from pre-commit? How do I interpret the gobbledygook after the DELTA # # # line? Are there any libraries that will help with that? Let's have some fun!
PS Seriously, no one's created a "bad-ideas" tag? WTF.
It is your build process that is flawed, not Subversion. If you must not commit passwords, do something like the following:
1 - Web.config files should not be committed. Instead, commit files like Web.config.dev or Web.config.qa.
2 - Have your build script rename the appropriate .config file to Web.config, and then do token replacement so that the proper passwords are inserted. This info can come from another file that is also not commited that says what environment you are in (so it knows which .config file to use), and what the passwords are.
This is something I've never really understood about source control, specifically Subversion (the only source control I've ever used, which isn't saying much). I'm considering moving to git or Mercurial, so if that affects the answer to my question, please indicate as such.
Ok. As I understand it, every time I create a new file, I have to tell SVN about it, so that it knows to add it to the repository and place it under control. Something like:
svn add newfile
That's fine if I'm the one creating the file: I know I created it, I know its name, I know where it lives, so it's easy to tell SVN about it.
But now suppose I'm using a framework of some kind, like Rails, Django, Symfony, etc., and suppose I've already done the initial commit. All of these frameworks create new files programmatically, often many at once, in different directories, etc. etc. How do I tell the source control about these new files? Do I have to hunt each one of them down individually and add them? Is there an easier way? (Or am I possibly misunderstanding something fundamental about source control?)
Generally speaking, you shouldn't add files to source control if they can be generated from other files in your project. It's true that in some cases, a file is initially generated, but must be modified manually. In that case you will have to add it to source control. However, you should almost never automatically add files.
I agree with Matthew in general, if it can be generated it shouldn't be added but remain dynamically created.
For the practical question of adding multiple files, I don't remember in svn (though I think it should be possible), but to do this in git:
Using git bash (command line) you can add all "loose" files under the directory or subdirectory by not specifying a file after the add command. You can also set git to ignore certain files, so they wont be added in that case.
Another way is using git gui, it displays all un-tracked files and you can select them all (or groups of it) and add them in one click.
I'm learning mercurial as my solo scm software. With other management software, you can put change comments into the file header through tags. With hg you comment the change set, and that doesn't get into the source. I'm more used to central control like VSS.
Why should I put the file history into the header of the source file? Should I let mercurial manage the history with my changeset comments?
Let the source control system handle it.
If you put change details in the header it will soon become unwieldy and overwhelm the actual code.
Additionally if the scm has the concept of changelists (where many files are grouped into a single change) then you'll be able to write the comment so that it applies to the whole change and not just the edits in the one file (if that makes sense), giving you a clearer picture of why the edit was required.
Yes; let the source control system handle your changeset comments. The rationale for this is that it makes considerably more sense when you're viewing the change log later, trying to work out what's going on between two versions of a file - the source control system can present the change comment to try and enlighten the situation.
There's no reason to manually maintain a file history when SCM software is much better suited to solve this problem. All too often I see partially-completed file histories in the source, which actually hurts, because people incorrectly assume it is accurate.
The difference is not whether it's a centralized or distributed VCS, it's more about what's being changed.
When I moved to .Net, the number of files updated for any individual change seemed to skyrocket. If I had to log the change in each file, I'd never get any real work done. By commenting on the set of changes, it doesn't matter how many files I had to update.
If I ever needed to identify all of the changes for a particular change, I can diff between the two versions of the project.
The biggest difference (and advantage) I saw when switching away from SourceSafe was the switch from file based to project based commits. As soon as I got used to that, I stopped adding change-log type comments to all of my files.
(As a side effect, I've found that my process description comments have gotten better)
I'm not a big proponent of littering the code with change comments. In the event they are needed they can be looked up in the SCM (at least for the SCM variants I have used). If you do want them in the file, consider putting them at the end instead of the beginning. That way you won't have to scroll down past the (uninteresting, to me at least) comments before you get to the actual code.
Another vote for letting the SCM system handle the checkin comments, but I do have one thing to add.
Some systems allow you to use RCS tags in your source code where the SCM can insert the change history directly into the source file being committed automatically. Sounds like a nice balance because the history is then in the SCM system and then automatically put into the source code itself.
The problem is that this process changes the source file. I think that's a bad idea because the file cannot be changed on disk until after you comment is inserted. If you were a good engineer, you should have built and tested changes before the commit. If your source changes after the commit, then you've essentially got a build that could be broken - but most engineers won't build after a commit - why should they?
But it's just a comment you say! True, but I did have a case where there was code in my source file that strangely enough had reason to look like an RCS header tag and that section of the code got replaced on checkin, thereby munging my code. Easy enough to fix, but bad that a build got broken for 20+ users
Much easier to forget to maintain history in the source, as one always (imo) should comment commits to source control system that problem dissappers. Also if changing lots of files before commit, changing history in every file will be annoying work. This is really one of the points with having scm.
I have experience with this. I've had the file history in the comments, it was awful. Nothing but garbage, sometimes you would have to scroll down almost 1k lines of code changes before you finally got to what you wanted. Not to mention, you're slowing down other aspects of your build process by adding more kb to your source code tree.