Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming Software IT

Programmer's File Editor With Change Tracking? 286

passionfingers writes "My business users regularly have to tweak large (>32MB text) data files manually. Overlords charged with verifying the aforementioned changes have requested that the little people be provided with a new file editor that will track changes made to a file (as a word processor does). I have scouted around online for such an animal, but to no avail — even commercial offerings like UltraEdit32 don't offer such a feature. Likewise on the OSS side of the fence, where I expected a Notepad++ plugin or the like, it appears that the requirements to a) open a file containing a large volume of text data and b) track changes to the data, are mutually exclusive. Does anyone in the Slashdot community already have such a beast in their menagerie? Perhaps there is there a commercial offering I've missed, or could someone possibly point me to their favorite (stable) OSS project that might measure up?"
This discussion has been archived. No new comments can be posted.

Programmer's File Editor With Change Tracking?

Comments Filter:
  • by FooAtWFU ( 699187 ) on Friday July 25, 2008 @11:54AM (#24336217) Homepage
    In the open-source world you edit your text file, finish for a bit, save it, and check it back into your favorite form of source control. You can then look at the diffs between various revisions.
    • by JBrow ( 668684 ) <{john.n.brow} {at} {}> on Friday July 25, 2008 @01:34PM (#24338011)
      Aside from using version control, I also have Emacs set up with an extensive save history. My settings are:

      ; backup
      (setq make-backup-files t)
      backup-by-copying t
      backup-directory-alist '(("." . "~/.saves"))
      delete-old-versions t
      kept-new-versions 6
      kept-old-versions 2
      version-control t)

    • Netbeans has subversion integration built into it, and function as a real-time diff from your working copy. It sounds like that would solve the problem the best. I don't use it myself anymore, and I don't know how it handles large files, but it's available on every platform, free, and will do what you asked. You do need to have a subversion repository, of course, though.
      • Re: (Score:2, Informative)

        by dthrall ( 894750 )
        No offense, but using a java ide to edit text files doesn't seem like the most efficient way to do things, especially dealing with 32mb files (I find most of the java-based ide's i've used tend to choke on large files... Sure, the diff viewer is part of the whole bundle, but for the subversion functionality, TortoiseSVN is a decent windows client, as it sounds like the person inquiring is a more non-technical user. Of course, I'm not sure if you actually mean a true OSS way of doing this, or if you're just
  • Version control (Score:5, Insightful)

    by Just Some Guy ( 3352 ) <> on Friday July 25, 2008 @11:55AM (#24336253) Homepage Journal

    You don't solve that by changing editors. You solve that by standardizing on a version control system and using it. For example, you could stick a Subversion server somehwere on your network, then install TortoiseSVN on your client machines. When you edit the file, you commit it with a log message of why you made the changes.

    This is infinitely preferable to forcing all of your developers to use one specific editor (which is the universal holy war among programmers), when all of them will be half-assed at best when compared to real version control.

    • Re:Version control (Score:5, Informative)

      by Shaitan Apistos ( 1104613 ) on Friday July 25, 2008 @12:02PM (#24336375)
      Some editors, netbeans for example, even have visual cues in the margin indicating what you've changed from the svn revision you've checked out since your last commit.
      • by Shados ( 741919 )

        Yeah, I just don't think a 32 meg file in netbeans with svn and the change tracking in the margin will be a very efficient way of editing the file though, considering these features in most such IDEs tend to start choking after a few hundred kilobytes.

    • by markov_chain ( 202465 ) on Friday July 25, 2008 @12:10PM (#24336501) Homepage

      You must switch to version control, urgently! []

    • by HiThere ( 15173 )

      I didn't get the impression that most of the users were to be programmers, and apparently he was explicitly instructed to find a text editor with version tracking. Naturally that's basically impossible.

      What would probably be acceptable, if it could be found, would be a programmer's editor that had it's own file format which kept track of changes, and a *really good* export feature which turned the current version into export text (in your choice of ASCII, UTF-8,-16, or -32).

      Version control is a good choice

    • So who's going to tell the boss he's nuts?
  • source control? (Score:2, Insightful)

    by MariusBoo ( 883340 )
    Are the overlords retarded? Just use source control (svn?). "Track changes" is evil.
  • diff -Nrau (Score:5, Informative)

    by red_dragon ( 1761 ) on Friday July 25, 2008 @12:00PM (#24336331) Homepage
    What's so bad about diff that you're not using it already? Certainly it would be a better choice for dealing with multiple text files: make a working copy (which can be an entire directory tree), do your changes on the working copy, and then run diff against the original and working copies. And I bet that there's an Emacs mode for that too.
  • CVS/SVN? (Score:5, Informative)

    by Jonah Hex ( 651948 ) <> on Friday July 25, 2008 @12:00PM (#24336345) Homepage Journal
    I understand you want an all-in-one, however I believe that most "programming" editors can hook into some sort of change management program. I use one locally with my AutoIT3 scripts and the SCiTE editor, every time I compile it asks me for a "changes/reason" and enters that into my own local source management.

    SCiTE []

    SCiTE for AutoIT [] with screenshots

    CVS/SVN wrapper for SCiTE [] with screenshots and instructions

    Jonah HEX
    • by nmb3000 ( 741169 )


      I've also used Scite for AutoIt and it does work very well, but in general Scite is a royal PITA to configure. If you want to change text styles or colors you have to wade through several mountains of configuration files, hunting for just the right line to change, restart the editor and hope you picked the right place to edit.

      For Windows users, Notepad++ [] is a much better solution. It uses the Scintilla editor engine so it has the same capabilities as Scite, but the configuration is all done through a

  • Custom tool (Score:3, Interesting)

    by CaseyB ( 1105 ) on Friday July 25, 2008 @12:01PM (#24336353)

    In addition to joining the chorus that will suggest you use version control, I'll put in a suggestion to write a custom tool to view and make specific changes to the file. Multiple users editing *data* files by hand, with no validation, is silly.

  • change the process (Score:5, Insightful)

    by DragonTHC ( 208439 ) <Dragon.gamerslastwill@com> on Friday July 25, 2008 @12:06PM (#24336423) Homepage Journal

    if your business users have to edit 32MB text files by hand, someone is a moron.

    Someone didn't know what they were doing in the first place.

    Change the process to make sense.

    Perhaps those "files" should actually be in a database. SQL makes automatic manipulation quite easy.

    • by blincoln ( 592401 ) on Friday July 25, 2008 @12:09PM (#24336477) Homepage Journal

      Perhaps those "files" should actually be in a database. SQL makes automatic manipulation quite easy.

      Exactly. That also makes it easy to build a change audit logging table.

    • by DragonTHC ( 208439 ) <Dragon.gamerslastwill@com> on Friday July 25, 2008 @12:11PM (#24336505) Homepage Journal

      come to think of it, it sounds like you're asking us how to best manage spam hit lists.

      • Re: (Score:3, Insightful)

        by cstdenis ( 1118589 )

        Thats silly. Spammers don't edit their lists. They just blast it out to all, valid or fake.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Agreed. Fix the real problem, which is "Having to hand-edit a 32 MB text file in the first place."

    • Re: (Score:3, Interesting)

      by qoncept ( 599709 )
      That's a pretty short-sighted comment. It's very easy to end up doing something that outwardly looks totally foolish. Maybe these files started out about 4kb (and as I imagine this example, I'm remembering when it happened in my project) and unforseen changes caused it to gradually grow to 32mb. Hand editing from the beginning wasn't a big deal, but now it is.

      Which brings up the issue of changing this "process." Have you worked in a fast paced environment with limited resoures? Processes don't just chang
      • Re: (Score:3, Informative)

        by Baddas ( 243852 )

        Sounds like they're in a non-sustainable environment. Once they run off the rails, or someone gets sick, or someone puts a comma where they shouldn't, the whole house of cards comes crashing down.

        Risk management via creating space to improve the process is surely a better option than that, right?

    • Re: (Score:2, Insightful)

      by jzu ( 74789 )

      Yes, CVS/SVN/whatever is a good technical answer to a bad requirement. You probably cannot change anything at the requirement level, however, so your best bet would be to report your findings in a very technical and neutral way... And, as a side note or even a line in the corporate summary, just point out the deficiencies in the process and possible solutions if you can imagine straigthforward ones, leaving options open. BTW, the word "risks" has magical powers.

  • Source Control (Score:5, Insightful)

    by Imagix ( 695350 ) on Friday July 25, 2008 @12:07PM (#24336439)
    I'll echo the same sentiments as everybody else... use source control. In addition, you're asking for the impossible. Word Processors can do "change tracking" within a file because the file contains more stuff than simply the text that you type in. Based on your description, the file you're talking about is simple text data, and has no provisions for storing "previous versions" directly within the text file. Where were you expecting this additional information to reside? And if it's in the same file, you would also have to change whatever tools you're using to process that file to be aware of all of this new (and to that tool, useless) information within the file.
  • diff (Score:5, Funny)

    by Anonymous Coward on Friday July 25, 2008 @12:07PM (#24336453)

    I just wrote one for you, and it is even using your favorite editor:
    cp $1 $1.bak
    `$EDITOR $1`
    diff $1.bak $1

    • Re:RCS (Score:3, Insightful)

      And here's one that will track previous changes as well as well as preventing edits by two people at once...

      $ cat
      co -l $1
      $EDITOR $1
      ci $1
      co $1

  • Wiki? (Score:4, Interesting)

    by mi ( 197448 ) <> on Friday July 25, 2008 @12:07PM (#24336459) Homepage Journal

    Sounds like Wiki may be the best... It is easy enough to split the document into sections, which can be edited concurrently. It keeps the history available. And the format is (almost) text.

    Pick MediaWiki [] (the same software, that powers WikiPedia) or any other implementation (some may be easier to operate on a small LAN, and/or be able to export pure text, etc.)

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Did you ever open a 32mb text file in a browser?
      Or edit it in a textbox inside a browser?

      (Even if you split it in sections of, say, 1mb, it's still not gonna work comfortably. And then we're not even talking about reassembling the pieces to get the original big file.)

      And, like someone else said, if you need to start tweaking text files bigger than 32mb, then something in your business processes is wrong.

      • by Fox_1 ( 128616 )
        yeah Mediawiki software has known issues with editing large files - more to do with the web browsers then with any failing on Mediawiki's part. Beyond that installing Mediawiki as a solution to this problems seems like a lot more overhead and extra work than is needed. Mediawiki is a collection of scripts and a SQL database. Unless you really want *those* particular Scripts and Database, it's probably easier to do what has already been suggested and just use a simple SVN solution or database.
  • by antifoidulus ( 807088 ) on Friday July 25, 2008 @12:10PM (#24336499) Homepage Journal
    Automatic file versioning built right into the file system! Problem solved! Next!
    • Of my limited 1 year of pain with VMS back in the 90s (the software got ported to Linux shortly after), I think the file versioning was awesome.

      We had a custom DIR alias to only show the current version, and custom purge scripts to keep the directories from becoming unwieldy.

    • by UnderCoverPenguin ( 1001627 ) on Friday July 25, 2008 @12:51PM (#24337201)

      If the users are using Linux, there is also ext3cow, which was discussed on /. (, the newly announced Tux3 (, Wayback ( and others.

    • Unisys OS2200 is better -- it supports file and directory "cycling" which is roughly similar to versioning, but you can also use a directory file ("program file") to store files ("elements") that are never actually delated (only marked as such) until the directory is packed. That means you can have dozens of older versions saved, but they don't clutter up your directory displays unless you choose to see them. :-)

  • Um, Eclipse? (Score:5, Informative)

    by Progman3K ( 515744 ) on Friday July 25, 2008 @12:14PM (#24336563)

    I seem to recall Eclipse saves your edit history

  • I think tracking changes should not be the job of the editor, but of something else that is good at it, like svn. I would let people use the editor they like, and add this [] script on their local machine to track changes. They can then commit the changes to the svn server and the Overlords can check out the changes (or any revision of them) from the main repo.

  • a new file editor that will track changes made to a file (as a word processor does)

    A large part of the 'as a word processor does' feature is that the file format itself supports it - all the changes are saved right along side each other and the word processor picks and chooses what to display to you at any particular point in time. If your file format does not support change tracking, you need to look at external change tracking solutions such as SVN/CVS or something on the file system level.

  • I use to use CodeWright for this.
    MS Visual Studio does this at work.
    Notepad++ does this for free at home.

  • It always does, for everything.

  • Basically, it's a realtime distributed editor, but has a native format that saves who authored what. Works really well. []

  • track changes made to a file (as a word processor does)

    A word processor (or other office application) can track changes because the format of the file is specifically designed to allow such tracking. You data files, which you imply are text, are just data. Unlike a word processing document file, the editor is showing you everything in the file - there is nothing in the file to provide for change tracking.

    Of course, the file format could be enhanced, but then everything that uses the data files would need to be changed.

    As suggested elsewhere, your best bet is to

  • Eclipse offers such a feature, but I need to ask what format is this 32MB file you are meant to be editing?

  • try SlickEdit (Score:2, Informative)

    by davido42 ( 956948 )
    I believe SlickEdit now supports change tracking directly. Not sure how well it works with plain text data files, but it is supported on several platforms, has hooks for version control integration, and so on.
  • Is it straight text? If so, does it have to remain straight text?

    Do the overlords want to be able to identify who made the changes, or just verify the changes were made and made correctly?

    Is there a reason the data is not in a DB, etc?

    Different answers result in different solutions.

  • Most any respectable programmer's editor has hooks for versioning and build systems. The nicest ones are Gedit and Geany.
  • by Bob9113 ( 14996 ) on Friday July 25, 2008 @01:02PM (#24337411) Homepage

    Overlords charged with verifying the aforementioned changes have requested that the little people be provided with a new file editor that will track changes made to a file (as a word processor does).

    Apparently your Overlords' heads have some fault code and need to be debugged.

    Revision tracking is accomplished with revision tracking software.

    You may think it is easier to just do what they are telling you to do, but in the long run it is not. They need to understand the difference between editing and revision tracking. If they do not, they will not be getting what they are looking for.

    There are a variety of methods for tracking revisions, from diff files to Subversion. Word processors store delta histories in the document, which is a poor place to store such things because it is insecure and liable to corruption.

    Then again, if you're doing hand edits to 32M text files, you probably are working in a company with less comprehension of information science than the City of San Francisco [] (alas, my beloved home city, but boy do they have their heads up their nether regions).

    Seriously - you may not like this answer, but it is the only correct one. Fix their understanding of revision tracking.

  • Keep your master copy in Microsoft Word with its Change Tracking turned on, then export it to .txt every time you save it. LOL. Perfect!

  • by answerer ( 626307 )
    I'm guessing the point of having change tracking is so that the Overlord can review and approve the changes. In that case, maybe UltraCompare( []) is what you're looking for?
  • diff (Score:3, Insightful)

    by slashflood ( 697891 ) <flow&howflow,com> on Friday July 25, 2008 @01:21PM (#24337755) Homepage Journal
    Keep a copy of the original file and make a diff []. Am I missing something?
  • One place I worked, the lead developer was paranoid and liked to review and understand every change I made to the code before "committing" it to his own tree. (Yeah they didn't use source control much either. Very stupid...) So we got really good at using WinMerge []. It has good keyboard shortcuts that let you step through the diffs between two files, one at a time, and merge them from one to the other.

    On Linux, meld [] is comparable (except the keyboard shortcuts are inferior, IMO, but you can probably chan

    • by Winter ( 87716 )

      WinMerge works under wine (version 2.4.x and 2.8.x at least, 2.6 didn't), and is actually my preferred merge utility under Linux.

  • by Trillan ( 597339 )

    The best text editor I've sen for tracking changes has to be e text editor []. I don't know if it's exactly what you want, but I think there's a demo so you can check it out. It falls down with 700MB files, but might do okay with 32.

  • I'll add my voice to everyone suggesting that you use a revision control system.

    Meld is a useful tool that lets you view diffs visually []. You can either ask it to diff two files or directories, or use the built-in subversion support. It shows the two versions of files side-by-side and highlights where stuff was added/deleted/modified.

  • I agree with the folks who suggest version control is the answer, but if for some reason that's a problem, there are definitely editors that do this. IntelliJ IDEA, the commercial Java IDE, has what it calls "local history" that tracks changes like this very well. It will track changes for any file it can edit, and tag the changes with date, username, etc.

As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs.