OS X has support for auto save and reverting to older file versions since Lion.
Are there any plans to support this in TextMate?
Is it hard to implement or there’s some other reason why it’s not supported? Maybe it’s just not on the priority list?
Thanks.
On 16 Oct 2014, at 17:03, Igor K wrote:
OS X has support for auto save and reverting to older file versions since Lion.
Are there any plans to support this in TextMate?
Is it hard to implement or there’s some other reason why it’s not supported? Maybe it’s just not on the priority list?
I guess it’s both; supporting it will, AFAIK, require TextMate to switch to using Apple’s stuff for document handling, which can be a bit of a straitjacket, so given that most TextMate users use third party version control, it hasn’t been a priority.
On 16-10-2014, at 17:03, Igor K me@igorkozlov.me wrote:
OS X has support for auto save and reverting to older file versions since Lion.
Are there any plans to support this in TextMate?
Is it hard to implement or there’s some other reason why it’s not supported? Maybe it’s just not on the priority list?
I regard Apple’s “versions” as quite useless.
Version control a la Mercurial, Git, svn is much te be preferred. Especially if you have a project that consists of several separate files. Apple will treat each file separately so versions of different files can easily be unsynchronised.
In addition Apple versions do not show highlighted differences between a current version and a previous version in the way that e.g. Changes, BBEdit and others do (for text files).
I much prefer proper version control (I mainly use Mercurial).
BTW: I’m not starting a flame war.
Berend
I agree.
Apple’s versioning system works fine for documents, spreadsheets and keynotes, but isn’t anywhere near as complete as what source code demands.
Caio
On 17 of Oct, 2014, at 12:08, Berend Hasselman bhh@xs4all.nl wrote:
On 16-10-2014, at 17:03, Igor K me@igorkozlov.me wrote:
OS X has support for auto save and reverting to older file versions since Lion.
Are there any plans to support this in TextMate?
Is it hard to implement or there’s some other reason why it’s not supported? Maybe it’s just not on the priority list?
I regard Apple’s “versions” as quite useless.
Version control a la Mercurial, Git, svn is much te be preferred. Especially if you have a project that consists of several separate files. Apple will treat each file separately so versions of different files can easily be unsynchronised.
In addition Apple versions do not show highlighted differences between a current version and a previous version in the way that e.g. Changes, BBEdit and others do (for text files).
I much prefer proper version control (I mainly use Mercurial).
BTW: I’m not starting a flame war.
Berend
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
IMO I don't think we need Apple to (indeed) help me with version control which is indeed what you actually want to use. I use git (with GitHub) and I'm very happy with it, when you get the hang of it it's pretty easy to use and there's a GUI as well if you want for easy merging branches etc. I love Mac but I think the existing tools for version control are perfect.
Cheers, Rolf
Berend Hasselman schreef op 2014-10-17 17:08:
On 16-10-2014, at 17:03, Igor K me@igorkozlov.me wrote:
OS X has support for auto save and reverting to older file versions since Lion. Are there any plans to support this in TextMate? Is it hard to implement or there's some other reason why it's not supported? Maybe it's just not on the priority list?
I regard Apple's "versions" as quite useless.
Version control a la Mercurial, Git, svn is much te be preferred. Especially if you have a project that consists of several separate files. Apple will treat each file separately so versions of different files can easily be unsynchronised.
In addition Apple versions do not show highlighted differences between a current version and a previous version in the way that e.g. Changes, BBEdit and others do (for text files).
I much prefer proper version control (I mainly use Mercurial).
BTW: I'm not starting a flame war.
Berend
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate [1]
Links: ------ [1] http://lists.macromates.com/listinfo/textmate
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
And I know for sure that not only developers use TextMate, so I was thinking that those people would also gladly embrace some simple versioning.
On 17-10-2014, at 17:33, Igor K me@igorkozlov.me wrote:
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but Apple versions doesn’t show or highlight differences. And that's what I don’t like about it.
Berend
And I know for sure that not only developers use TextMate, so I was thinking that those people would also gladly embrace some simple versioning.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
For your use case, sure. You're ignoring that other people might find it very helpful for theirs.
Use your preferred tools, and let others request ones for themselves. Adding in Apple file versioning in no way impinges or alters your ability to use a more suitable tool for yourself, so I'm at a loss as to why you felt the need to speak out against it.
Now, if you're suggesting that file difference highlighting be layered over the top of Apple versioning, great, that sounds like a nice enhancement, and I'm sure that we can have an interesting discussion on the technical feasibility. However, it sounds more like you're simply saying "Well *I* don't think it's useful so we shouldn't go that direction." That isn't very productive.
-- Jason
On Oct 17, 2014, at 8:39, Berend Hasselman bhh@xs4all.nl wrote:
On 17-10-2014, at 17:33, Igor K me@igorkozlov.me wrote:
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but Apple versions doesn’t show or highlight differences. And that's what I don’t like about it.
Berend
And I know for sure that not only developers use TextMate, so I was thinking that those people would also gladly embrace some simple versioning.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 17 Oct 2014, at 17:39, Berend Hasselman bhh@xs4all.nl wrote:
On 17-10-2014, at 17:33, Igor K me@igorkozlov.me wrote:
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but Apple versions doesn’t show or highlight differences. And that's what I don’t like about it.
That would typically be something that the app itself (i.e. TextMate) would do.
A checkbox in the Save sheet when first saving a new document where you can choose to use Apple’s versioning system would be a useful addition to Textmate IMO.
Best regards, Bas
I would whole heartedly agree that Apple’s versioning is not a replacement for code versioning systems and because I commit a lot during the day I don’t have much of any use case for Apple’s versions but as long as it this functionality were “in addition to” then I see no harm as it would provide the ability to move back and forth between recent versions of the file within the commit cycle. I have had situations where it would be nice to go back in time 4 hours to remind myself what the state of this file was then (assuming I haven’t committed these changes during the timeframe). So there is a use-case for it I think and if it’s easy to “turn on” then I think it would be better with than without but if there’s a lot of effort in making it work I personally think it would be a waste of time.
Ken
p.s. another use-case would be that people do use textmate for document processing (it’s a great markdown editor when paired with marked) … in this situation you might be back in the more individual (versus team) and non-developer workflows that Apple is primarily catering to
On 17 October 2014 at 17:10:40, Caio Fernando Bertoldi Paes de Andrade (caiofbpa@icloud.com) wrote:
I agree.
Apple’s versioning system works fine for documents, spreadsheets and keynotes, but isn’t anywhere near as complete as what source code demands.
Caio
On 17 of Oct, 2014, at 12:08, Berend Hasselman bhh@xs4all.nl wrote: On 16-10-2014, at 17:03, Igor K me@igorkozlov.me wrote:
OS X has support for auto save and reverting to older file versions since Lion. Are there any plans to support this in TextMate? Is it hard to implement or there’s some other reason why it’s not supported? Maybe it’s just not on the priority list?
I regard Apple’s “versions” as quite useless. Version control a la Mercurial, Git, svn is much te be preferred. Especially if you have a project that consists of several separate files. Apple will treat each file separately so versions of different files can easily be unsynchronised. In addition Apple versions do not show highlighted differences between a current version and a previous version in the way that e.g. Changes, BBEdit and others do (for text files). I much prefer proper version control (I mainly use Mercurial). BTW: I’m not starting a flame war. Berend _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
_______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 17-10-2014, at 17:55, Bas Van Klinkenberg txmt@vanklinkenbergsoftware.nl wrote:
On 17 Oct 2014, at 17:39, Berend Hasselman bhh@xs4all.nl wrote:
On 17-10-2014, at 17:33, Igor K me@igorkozlov.me wrote:
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but Apple versions doesn’t show or highlight differences. And that's what I don’t like about it.
That would typically be something that the app itself (i.e. TextMate) would do.
A checkbox in the Save sheet when first saving a new document where you can choose to use Apple’s versioning system would be a useful addition to Textmate IMO.
Or the method used by NeoOffice: a menu item giving you a choice to disable/enable.
Berend
I can see where that may be an issue, given my thin understanding of versioning in Apple's document model. IIRC, you can declare a document versioned or not, but there's no turning it on or off after creation. Can anyone confirm this?
I think adding versioning to the mix as an option is interesting for those who use TextMate as a ToDo editor, for simple one-offs outside of larger projects, and so on. I can see myself using it in those situations, and continuing to use hg and git for my significant projects, both source and document (LaTeX mostly) based.
If TM were to then provide that diff highlighting on top of the versioning, that would, I think, be a rather spiffy feature set. I have a suspicion that integrating Apple's versioning into the current SCM handling model of TM would be a significant amount of trouble, but it would be rather slick if possible.
On Fri, Oct 17, 2014 at 10:43 AM, Berend Hasselman bhh@xs4all.nl wrote:
On 17-10-2014, at 17:55, Bas Van Klinkenberg < txmt@vanklinkenbergsoftware.nl> wrote:
On 17 Oct 2014, at 17:39, Berend Hasselman bhh@xs4all.nl wrote:
On 17-10-2014, at 17:33, Igor K me@igorkozlov.me wrote:
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but Apple versions doesn’t show or highlight
differences. And that's what I don’t like about it.
That would typically be something that the app itself (i.e. TextMate)
would do.
A checkbox in the Save sheet when first saving a new document where you
can choose to use Apple’s versioning system would be a useful addition to Textmate IMO.
Or the method used by NeoOffice: a menu item giving you a choice to disable/enable.
Berend
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Igor K wrote (Fri, 17 Oct 2014 18:33:14 +0300):
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but when Allan says that supporting Apple's versioning "can be a bit of a straitjacket" I fear that it might have some disadvantages, so IF that is the case I'd prefer TextMate not to support it.
Just like you, I use TextMate on a lot of "non-development" files that aren't located in a git repository, so I use Michael Lehmkuhl's way to "Backup on save": http://wiki.macromates.com/Main/Howtos#BackupOnSave
... well, I changed it a bit to include the original path in the backup path, i.e. when the file I'm working on is /Users/tob/Documents/PlainText/Articles/SomeFile.txt it'll be backuped as /Users/tob/TextMate-Backups/20141017/Documents/PlainText/Articles/SomeFile.txt.201410117200614.tmbackup
Of course, this doesn't provide any kind of interface to browse those files so you have to rely on the Finder; but it works well for me.
Kind regards, Tobias Jung
Put me down for another person who wouldn't find this useful personally.
Thats not a reason not to add it, but IF it's added, Id really hope it doesn't interfere with TM's ability to over AFP/NFS, on remote filesystems that don't support versioning.
On 17/10/2014, Tobias Jung mylists@ct-jung.de wrote:
Igor K wrote (Fri, 17 Oct 2014 18:33:14 +0300):
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but when Allan says that supporting Apple's versioning "can be a bit of a straitjacket" I fear that it might have some disadvantages, so IF that is the case I'd prefer TextMate not to support it.
Just like you, I use TextMate on a lot of "non-development" files that aren't located in a git repository, so I use Michael Lehmkuhl's way to "Backup on save": http://wiki.macromates.com/Main/Howtos#BackupOnSave
... well, I changed it a bit to include the original path in the backup path, i.e. when the file I'm working on is /Users/tob/Documents/PlainText/Articles/SomeFile.txt it'll be backuped as /Users/tob/TextMate-Backups/20141017/Documents/PlainText/Articles/SomeFile.txt.201410117200614.tmbackup
Of course, this doesn't provide any kind of interface to browse those files so you have to rely on the Finder; but it works well for me.
Kind regards, Tobias Jung
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
+1 for not being useful too (not against adding it tho)
On October 17, 2014 at 12:55:28 PM, Carpii UK (carpii.uk@gmail.com) wrote:
Put me down for another person who wouldn't find this useful personally.
Thats not a reason not to add it, but IF it's added, Id really hope it doesn't interfere with TM's ability to over AFP/NFS, on remote filesystems that don't support versioning.
On 17/10/2014, Tobias Jung mylists@ct-jung.de wrote:
Igor K wrote (Fri, 17 Oct 2014 18:33:14 +0300):
Well I use Git myself a lot, but mostly for development.
Sometimes though I’m working on some random text files, like articles or markdowns that are not being versioned and initing a git repository for each and every of them sounds like a really bad idea.
I see your point but when Allan says that supporting Apple's versioning "can be a bit of a straitjacket" I fear that it might have some disadvantages, so IF that is the case I'd prefer TextMate not to support it.
Just like you, I use TextMate on a lot of "non-development" files that aren't located in a git repository, so I use Michael Lehmkuhl's way to "Backup on save": http://wiki.macromates.com/Main/Howtos#BackupOnSave
... well, I changed it a bit to include the original path in the backup path, i.e. when the file I'm working on is /Users/tob/Documents/PlainText/Articles/SomeFile.txt it'll be backuped as /Users/tob/TextMate-Backups/20141017/Documents/PlainText/Articles/SomeFile.txt.201410117200614.tmbackup
Of course, this doesn't provide any kind of interface to browse those files so you have to rely on the Finder; but it works well for me.
Kind regards, Tobias Jung
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
_______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 17 Oct 2014, at 19:01, Jason McC. Smith jason@ncpod.org wrote:
I can see where that may be an issue, given my thin understanding of versioning in Apple's document model. IIRC, you can declare a document versioned or not, but there's no turning it on or off after creation. Can anyone confirm this?
Would you *please* follow mailing list convention with regard to where you place your reply in relation to the quoted text.
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
On 21 October 2014 15:52, Justin Catterall 100621.1@masonsmusic.co.uk wrote:
On 17 Oct 2014, at 19:01, Jason McC. Smith jason@ncpod.org wrote:
Would you *please* follow mailing list convention with regard to where you place your reply in relation to the quoted text.
Fair point. I'm guessing I'm one of the people you're referring to?
Lets be honest though, majordomo style lists are a bit archaic these days. I know I've replied to the list before and my reply has ended up appearing as a top level thread, although I've still no idea why.
I'm sure Im not alone in wondering exactly what the bare minimum is I need to quote, in order for it to appear threaded. If you're happy to guide us through that, Im sure I wouldn't be the only one to benefit from it.
On 24 Oct 2014, at 00:56, Carpii UK carpii.uk@gmail.com wrote:
On 21 October 2014 15:52, Justin Catterall 100621.1@masonsmusic.co.uk wrote:
On 17 Oct 2014, at 19:01, Jason McC. Smith jason@ncpod.org wrote:
Would you *please* follow mailing list convention with regard to where you place your reply in relation to the quoted text.
Fair point. I'm guessing I'm one of the people you're referring to?
Lets be honest though, majordomo style lists are a bit archaic these days. I know I've replied to the list before and my reply has ended up appearing as a top level thread, although I've still no idea why.
I'm sure Im not alone in wondering exactly what the bare minimum is I need to quote, in order for it to appear threaded. If you're happy to guide us through that, Im sure I wouldn't be the only one to benefit from it.
I was not suggesting you (or others) were quoting too much that was unnecessary, just *where* you (and others) were putting your reply. I agree that, in a technical discussion, if you're the one asking about something you aren't very familiar with, it can be very difficult to know what is relevant and what is not. I have no problem with erring on the side of caution and quoting everything if you don't feel you can discern what can be cut.
This mailing list, at least at the moment, has a reasonable amount of traffic. For those following it it is essential that doing so is as efficient as possible, we've all got jobs to be doing and following this mailing list isn't a relaxing pastime, we want to extract the content and move on as quickly as possible. So, for this to happen, it is better if we all stick to the same posting conventions.
Writing, quoting and posting this way may be archaic, but that doesn't mean it's broken.
-
Allan Odgaard -
Bas Van Klinkenberg -
Berend Hasselman -
Caio Fernando Bertoldi Paes de Andrade -
Carpii UK -
Igor K -
Jason McC. Smith -
Jason Smith
-
Justin Catterall -
Ken Snyder -
Rolf Langenhuijzen -
Tobias Jung -
William Pickens