Forgot your password?
typodupeerror
Programming Software IT

Programmer's File Editor With Change Tracking? 286

Posted by kdawson
from the and-a-pony dept.
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:
  • 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.

  • Re:Version control (Score:1, Interesting)

    by Oh no, it's Dixie (1332795) on Friday July 25, 2008 @12:06PM (#24336427)
    I know for a fact that Eclipse has this feature as well.
  • Wiki? (Score:4, Interesting)

    by mi (197448) <slashdot-2012@virtual-estates.net> on Friday July 25, 2008 @12:07PM (#24336459) Homepage

    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 [mediawiki.org] (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.)

  • "not to sound like a..." TOO LATE!

    Why complain? Too many people on slashdot are whiners! If you don't want to help, don't respond! That is the beauty of "open source". Help if you want or don't.

    I have been programming for over 30 years and am considered a guru by my peers. But I know my limitations. For example I would not touch a SAP project with out help, because I have no experience.

    Maybe the solution for everyone, is to have a category for "I need help" that people like you can tell slashdot not to show on your home page.

    For those who are not observant: this comment is recursive and sarcastic.

  • by pjt33 (739471) on Friday July 25, 2008 @01:06PM (#24337481)

    When I was young, we used RCS and we liked it! As the state of the art changes, so do the requirements to stay at the top. It's possible that SVN 1.5 qualifies as real version control by modern standards - I'll find out when it reaches my somewhat conservative distro - but previous versions have poor support for merging.

    I'm also rather unhappy at SVN this week because it managed to get itself in a horribly confused state in which it told me I needed to run svn cleanup to fix some locks, but running svn cleanup just got me an error message saying that I needed to run svn cleanup to fix the locks. I ended up having to delete and do a clean checkout, and was not impressed.

    As to the accusations of Linus fanboydom (yours is the second), the only reason I mentioned git is that I used it in my previous job and it worked well. I could equally have said Mercurial or BitKeeper, but since I have no experience with those I can't really recommend them.

  • by qoncept (599709) on Friday July 25, 2008 @01:18PM (#24337699) Homepage
    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 change. Projects just like this are thought up, planned, and indefinately postponed because they don't have extra resources to devote to the two months it would take to rewrite the process, allocate hardware, set up a database, migrate the data, train the users, test, install client software and so on.

From Sharp minds come... pointed heads. -- Bryan Sparrowhawk

Working...