Suppose I generate diff of my project before commit, let say using svn. Having one diff for all files in project is a very nice way to review changes before committing them. However sometimes I wish to edit those changes without reopening each file, simple edit the diff and have it reapplied. So I have made such key map(I have setup svn diff to use unified format with fair amount of surrounding lines):
map scde :w! tmpdiff<cr>:!svn revert -R .<cr>:!patch -p0 <tmpdiff<cr>
It works, but only partially; you can edit added lines, but if you mark lines as removed or want to add another line you get some trouble since specified diff ranges do not match with actual text present in the diff. One can update them for simple changes like adding a line, however it is tedious and quickly gets complicated if you make more sophisticated changes. Is there a way to edit diff in so that range would automatically update correctly? I have found that emacs has some diff mode for this(however I have not tried it), however I was unable to find solution for my needs using vim. Maye there someone can give some suggestions?
take a look at rediff. It automatically fixes the offsets within a patch file.
Related
I opened a Modelica library in Dymola, changed one line, closed Dymola and clicked "Save all", now TortoiseSVN is showing several hundred changed files instead of just one file with the one line changed I intended to do. All these changes are either whitespace, or line breaks, introduced by Dymola it seems.
Of course I can now be careful to only commit the file I have changed (and revert the rest), but that makes committing more time-consuming and error-prone than it needs to be. Or I can just commit it all, but that makes it hard for my colleagues to review the change. Also, it feels like it is not deterministic, so a later commit might just revert parts back. I sometimes even revert all changes, then use a text editor to change just the one line. All this makes version control unnecessarily complicated.
When I look at the commits and diffs for e.g. the Modelica Standard library:
https://github.com/modelica/ModelicaStandardLibrary/commits/master
The diffs are nice and small and readable usually. Is there a trick to avoid the whitespace issue?
How I can I turn off all autoformatting by Dymola? Is there a technical reason to do it in the first place?
You can reduce (but not entirely prevent) this behavior as follows:
Increase the maximum line length, e.g. to 130
In the GUI: Options > Text Editor > Max line length
From the command line: Advanced.MaxLineLength=130
Let Dymola format your whole library one time
Open the text view of the top-level package
Mark everything with Ctrl+A
Auto-format with Ctrl+Shift+L or Right-Click > Auto-Format
Save everything with Ctrl+Shift+S
Now go through the changes. Most will be useful, but sometimes spaces are removed, which you usually like to keep (especially before import and extends statements. They are sometimes moved to the very left)
Commit the changes
From now on try to save individual models only, not packages
(When packages are saved, Dymola sometimes reformats the nested classes)
There are some things you can do to make pretty git commits for Modelica code:
Use a text editor instead of a graphical editor. You have absolute control of what you change.
Use a graphical editor that does not change whitespace. I'm not sure of other alternatives, but OpenModelica/OMEdit will preserve existing indentation as much as possible (it can also be used to minimize diffs from changes in other tools, but it works less and less well the more changes there are).
Use a formatter as a pre-commit hook (indenting all files according to some settings in the formatter; but then you can't manually change whitespace).
Hope someone on stackoverflow has more alternatives than this.
I have, in perforce, a sort of 'basic working set' of files that I keep checked out (and therefore writable) when working. However, every time I commit my changes, this list gets disrupted - some things committed, others reverted - and then I have to waste time tracking down and checking out all these files again.
So, is there some way to save the list of currently checked out files, and then later check out those same files again?
I primarily use P4V, but I have P4Win and command-line Perforce available. I'd strongly prefer a GUI solution, though.
I only want to save and restore the state of which files are checked out, not the contents of those files, so shelving is not the answer
I am aware of the 'Do not submit unchanged' and 'Check out after submit' options. They are not sufficient. For instance, frequently I will have files which are programmatically generated which register as 'changed' when the only thing that is different is the 'File generated on' timestamp; I need to prevent such spurious revisions from being submitted, and I have not found any practical method of searching for and managing such files that doesn't involve the 'revert if unchanged' command.
You can do:
p4 -ztag opened | grep depotFile | cut -d ' ' -f 3 > files.txt
to save a list of files already open in your client. (If you don't have Unix utilities for Windows, you could construct this list by whatever means you want, such as running p4 opened > files.txt and manually editing files.txt in an editor.)
Once you have a list of files, you can open all of them via:
p4 -x files.txt edit
This doesn't meet your preference for a GUI-based solution, but you could create .cmd scripts to perform these actions and then double-click on them (or on shortcuts to them).
The easiest solution would be to exclude those generated files via your workspace specification, e.g., "-//depot/files/ignorablefile.sh"
They can still reside in your local workspace, but the app will not attempt to update them or add them to source control.
You said that shelving's not the answer, but that's what I would go with as the easiest solution (i.e. the one that involves the least scripting and/or fewest manual steps) for the specific question you're asking:
Shelve your pending change (let's call this change 1000).
Move your open files to a new pending change (let's call this change 1001).
Submit change 1001.
Unshelve change 1000.
Sync and resolve.
Now you have the same exact files open (the unshelve opened them) but at the head revision (the sync and resolve does that).
Now, looking past what you asked for to what might make your life easier: rather than reverting the files you don't want to submit (and having some sort of scheme to get them back later, possibly via shelving as described above), what I'd do is move them to another changelist. So instead of:
Identify "unchanged" files.
Revert unchanged files.
Submit remaining files with "reopen" option.
Reopen previously reverted files (somehow).
I'd do:
Identify "unchanged" files.
Move unchanged files to another changelist N.
Submit remaining files with "reopen" option.
Move all files from changelist N back to the default changelist.
All of those except step 1 are simple one-shot commands that you can do from any client. Personally, I'd automate steps 1+2 with a script (I'm assuming it's programmatically possible to determine whether the only diff in one of these files is the timestamp) and put it into P4Win/P4V as a "custom tool".
I have set vim as the svn editor.
Now, whenever I do 'svn ci', it opens up vim editor allowing me to enter the commit comments.
Below the comment section, there are set files which will be checked in. So, If I don't want certain files to be committed, I remove it from the list of files in the vim editor. But when I save and quit the vim editor, svn still checks-in the file I have removed in the editor.
Is this expected behavior? Or I need to set something in the svn configuration to make it work?
That list of files in the comments section is... well... just comments. It doesn't really do anything - it's just there to help you by letting you see what you are committing.
If you want to not commit certain files, you have to do it beforehand:
You can specify the files you want commit in the svn commit command instead of committing everything.
You can add the ignored files to your svn:ignore property.
You can use some GUI tool that'll let you visually select what to commit and what not.
There is some trick with changelists. Haven't tested it(I don't use SVN since it's crap), just found it in this answer when I googled.
Use Git with git-svn, and simply git reset HEAD the files you don't want to commit to unstage them.
The list in the editor is just informative; it tells you what will be committed but does not influence what will actually be committed (the relationship is the other way round). If that's not what you wanted, you have to kill the svn ci (typically by doing Ctrl+Z and then issuing the kill at the command line). To change what is committed, you need to list the files explicitly to svn ci; it only defaults to all known, modified files (i.e., those listed when you run svn status).
If the above way of working isn't to your taste, you might be better off getting one of the many GUIs that wrap around SVN. They almost universally make interactively selecting what to commit easier.
Is there a program (preferably available on Cygwin) which I can use to "filter" a diff file interactively? i.e. I want something like git interactive add, except that I want to operate on a diff file. I have already discovered filterdiff, but I don't think that it supports interactive editing, only inclusion/exclusion of hunks based on a pre-defined search criteria.
My usage scenario: I have a patch in MQ, which I would like to split up per the tutorial here: https://www.mercurial-scm.org/wiki/MqTutorial#Split_a_patch_into_multiple_patches. In order to do so, I have to edit a patch file so that it includes only the (many) changes I want, and doing this manually with a text editor is kind of a pain.
Thanks!
You can probably get what you want using the record extension: https://www.mercurial-scm.org/wiki/RecordExtension
Apply the patch (but don't commit it) and then selectively commit chunk by chunk using record. You could do that with or without mq in the works.
Emacs’ diff-mode has commands to (un)apply or delete individual hunks of a diff. It also allows editing the hunks (keeping the hunk headers up to date automatically), and it has a hunk-split command that is a bit more powerful than that in git add -p.
Any tips on how to store large amounts of text, such as programming code. So I need to retain the tabs, spaces, etc?
Also how could i keep versions like say someone edits one line, i can see the changes that have been made?
That's what various revision control systems are for.
Any of git, cvs, rcs, subversion and a host of others will work.
I agree with other posters that you probably want to use what has already been done. Sometimes rolling your own can be fun.
You could write a wrapper for the command line diff utils. Each user could have their own config to choose their preferred editor. The script would made a copy of the file, so you would have an orig and new. When done editing the script would kick off a diff and store that to disk and delete the original backup of the file. This way, you would only store the latest versions plus all diffs so you can revert back and also see the changes.
I would keep a log of all diffs created and tag them in a csv with the userid of the person who modified the file and the timestamp of the modification.