Re: Feature Requests
Totally agree that checkboxes in a commit dialog makes much more sense with large, deeply nested projects than manually selecting everything you want to commit. I had to deal with this for several months on a large project and believe me, it would be much faster to have checkboxes presented. As long as they're all checked by default, this doesn't change your normal workflow, so what's the big deal? Tested Cornerstone a bit recently... interface is definitely more clunky than Versions. Overall I think Versions still has the edge, despite its quirks, but man, if the browser columns would stay put and the commits/updates were non-modal, there'd be no contest. :) -Gabriel On Nov 19, 10:14 am, Kevin Powick wrote: > On Nov 19, 12:08 pm, Asbjørn Ulsberg wrote: > > > the workflow Quinn lays out is the same I have with SmartSVN and > > it's so much simpler to do than the cmd+click option, which is really > > impossible if you have a both wide and deep folder hierarchy. > > Agreed. It is much faster/easier to just click "commit" and be > presented with tidy checkbox list. Adding such a feature should in no > way alter the workflows or file inclusion methods that other posters > already use. > > Btw, due to recent issues with Versions, I've been evaluating > Cornerstone and it does have the checkbox feature. Though I still > find Versions' interface slightly cleaner, Cornerstone is impressive, > and the longer I wait for features and fixes, the more I'm inclined to > switch. > > -- > Kevin Powick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Problem: Google Code SSL certificates
Hi, I've seen this problem on both of my Macs running Versions for the past few days. It's maddening. Restarting Versions doesn't seem to help. Jeffrey On Nov 18, 3:09 am, Ero Carrera wrote: > Today I restarted versions, told it to accept the certs and so far > hasn't prompted me again. It appears that the problem has gone away. > > -- > ero > > On Nov 17, 7:15 pm, Ero Carrera wrote: > > > I follow a few projects in Google code, some are mine and some from > > other people. Since very recently (today 17/11/2009) I've been > > constantly getting this complaints about the certificates. I get a > > bunch, seemingly one for each of the projects I'm subscribed. Me being > > a bit paranoid first I inspected it briefly and looked "normal" so I > > accepted it for the session only, later, as it kept appearing I've > > tried to reject them and accept them always... with no different > > results. > > > A fix or workaround would be highly appreciated. Let me know if > > there's any additional information I could contribute. > > > Thanks, > > -- > > Ero > > > On Nov 17, 6:25 pm, Dirk Stoop wrote: > > > > Some people have reported that while Versions is running, they get an > > > SSL certificate acceptance dialog over and over. > > > > For me and some other people in our team this has started happening > > > yesterday evening, but only with the SSL cert. used by Google Code. > > > > If you are experiencing this same problem, or if you also have > > > authenticated Google Code repository bookmarks in Versions, but aren't > > > running into this problem, please drop us a line in this thread. We > > > are investigating the problem, but would like your feedback to help > > > figure out how high of a priority we should give to this problem. If > > > only a couple of people are running into this problem, we'll look for > > > a workaround first, if a lot of people are running into this issue, we > > > may have to adjust our planning for what/when the next Versions update > > > is going to be. > > > > Thanks! > > > - Dirk > > > > the Versions team --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
On Nov 19, 12:08 pm, Asbjørn Ulsberg wrote: > the workflow Quinn lays out is the same I have with SmartSVN and > it's so much simpler to do than the cmd+click option, which is really > impossible if you have a both wide and deep folder hierarchy. Agreed. It is much faster/easier to just click "commit" and be presented with tidy checkbox list. Adding such a feature should in no way alter the workflows or file inclusion methods that other posters already use. Btw, due to recent issues with Versions, I've been evaluating Cornerstone and it does have the checkbox feature. Though I still find Versions' interface slightly cleaner, Cornerstone is impressive, and the longer I wait for features and fixes, the more I'm inclined to switch. -- Kevin Powick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
I've worked with Eclipse and TortoiseSVN, and work daily with Versions and SmartSVN. The workflow Quinn lays out is the same I have with SmartSVN and it's so much simpler to do than the cmd+click option, which is really impossible if you have a both wide and deep folder hierarchy. If you do something wrong when trying to just select the correct files, your selection is suddenly gone, you've selected the wrong file(s) or something else. I'm not trying to plug SmartSVN here, but it's a more mature SVN client than Versions, so it's only natural that it has more features built in. One other such feature in the commit dialog I really love with SmartSVN that works excellently with the workflow in question is to preview the changes made to each and every file inside the commit window, which makes it extremely easy to spot which files you should remove the checkbox on and not. So basically, cmd+click works in theory, but is utterly useless (at least for me) in practice. :) -Asbjørn On Thu, 19 Nov 2009 16:57:12 +0100, Hardy Macia wrote: > > I've only done the selective commits by selecting files that I want to > commit, not the other way around as you are suggesting, but isn't what > you want to do just... > > Show changed files, select all, cmd-click the file/files you don't want > to commit? > > I've only used Eclipse once for a small project, but I found it > extremely annoying to use. > > -Hardy > > On Nov 19, 2009, at 10:50 AM, Quinn Taylor wrote: > >> It's a matter of workflow preference. Yes, you can select files and >> folders in the main GUI before committing — command-clicking etc. >> obviously works, but just because something is possible doesn't mean >> that's the only way anyone would/should ever want to do it. (Exhibit A: >> Windows) However, it can be a pain for deeply-nested hierarchies and >> excluding that one file that shouldn't be committed yet. The SVN >> plugins for Eclipse provide checkboxes in the commit window, and they >> can be incredibly handy when you need them. However, I generally only >> use them for *removing* files from the commit, so perhaps an >> unobtrusive button in the bottom left corner (which allows you to >> exclude 1 or more selected entries from the commit, without changing >> the selection in the main window) would be a good compromise? >> >> - Quinn >> >> On Nov 19, 2009, at 7:38 AM, Hardy Macia wrote: >> >>> >>> I'm always submitting a few files from versions so that I can submit >>> related file changes together. >>> >>> Cmd-click/shft-click on the files to select the ones you want to >>> submit and submit them. I think checkboxes would get in the way. >>> >>> - Hardy >>> >>> On Nov 19, 2009, at 10:35 AM, tom.dev...@googlemail.com wrote: >>> @Tomo "I personally often work on more than one thing on a project, and when I want to commit, I would like to be able to commit different things seperately. " Could you not just selected individual files to commit in the list view or am I missing something? "Versions should also know that I have new files and offer me to add them automatically before commiting" Totally agree with this tho :) On Nov 17, 2:11 pm, Ryan wrote: > I have to agree with Asbjørn on both counts. > > On Nov 16, 2:43 pm, Asbjørn Ulsberg wrote: > > > >> On Mon, 16 Nov 2009 16:35:54 +0100, Ray >> wrote: >>> I agree with the commit UI changes, but this is a workflow issue. > >> For some use cases, I agree this is a workflow issue, but for >> others it >> isn't. You might want to partially commit your entire working >> directory >> because you've been working on several different tasks at once and >> only >> want files related to task X commited, but not those related to >> task Y. > >> In such use cases, a checkbox beside each modified file would be >> neat. > >>> I keep a skeleton default config file versioned, and the actual >>> config >>> file ignored. Then you never have to worry about committing this >>> file. > >> I do the same thing. Works like a charm. That is, until you change >> the >> skeleton file and forget to update the unversioned config file. ;) > >> -- >> Asbjørn Ulsberg -=|=- asbj...@ulsberg.no >> «He's a loathsome offensive brute, yet I can't look away» --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
Simply put, because Versions doesn't care whether or not a file is selected if a parent directory is selected. (sigh) Because it's often a lot more work than removing a single resource, and as I've stated, with hierarchical selection, it can be non-trivial to select "everything but". No offense to anyone, but the replies to this thread are starting to sound increasingly dogmatic. I'm not a noob, I've been using Versions since the beta and Subversion for several years. I build SVN from source at work, and I deal with scenarios like I'm describing quite regularly. If it were as trivial as everyone makes it sound, I wouldn't write such lengthy responses. If I had time, I'd record a screencast to describe what I'm talking about, but I don't. Here's a simple scenario: in a working copy with at least one parent directory and one modified file, select all, then command-click the modified file. It shows up in the commit window, doesn't it? If you have 10 changed files, but only want to commit 8, try selecting all, then command-clicking the 2 to exclude and committing. You get all 10 files. The only way to do it currently is select at individual files — you can shift-click to select the 10, then command-click the 2. At this point, it's only a very mild annoyance. Now expand the example. Consider 10 sub-projects, each with Java source hierarchies where the directory structure (representing Java packages) usually extends ~10 levels deep from the working copy root. (Now consider that I've just done some major refactoring that touches files in multiple projects, but not all of them. For the sake of exaggerated example, let's say that there is a modified file at every level of every hierarchy, and the only ones we want to exclude is the single deepest file in each project hierarchy. To build up such a commit set, one has to command-click each file to commit individually, OR select all and deselect every parent directory and the files to exclude. Either way, you're looking at command-clicking roughly half of the individual entries displayed in the Changed view, since folder hierarchies appear if anything inside changed. Ballpark guess, that's about 100 clicks prior to being able to commit, assuming no error. Now consider if I could just click Commit with nothing selected, then manually exclude the 10 files in the commit window. Obviously, this is a contrived example, but not so much as you'd think. At work, I'm dealing with a working copy with 20 sub-projects that are all part of a massive Java server app, and the hierarchies are actually this deep. I don't have such bizarre contrived selection patterns, but there are many more than one file at each level of the hierarchy, and selection quickly becomes tiresome. That's why I (and others) are requesting the feature. A GUI is supposed to make things easier, and this is a case where including individual paths in Terminal would be horrific in comparison. Hope that makes sense. - Quinn On Nov 19, 2009, at 8:21 AM, Marijn Huizendveld wrote: > > Quin, > > I get your point. Why not expand your hierarchy select them all with > shift click and deselect the folders and the items you wish to exclude > with command click? > > - Marijn > > On Nov 19, 2009, at 5:18 PM, Quinn Taylor wrote: > >> I think you're misunderstanding my point. I'm not extolling the >> virtues of Eclipse, I also find it annoying in many ways, but for >> large Java projects, it does redeem itself. (FWIW, configuring a >> project is IMO the absolute worst part of Eclipse. Once you get past >> that, working with it isn't half bad, especially for an all-Java >> app.) I was only making a point of how the SVN plugins act in >> Eclipse to provide a concrete example. >> >> The approach you specify doesn't work in many situations. Imagine >> you have a Java package hierarchy with classes scattered up and down >> 6+ levels of it. If you don't want to commit everything in the >> hierarchy, selecting everything and deselecting resources not to >> commit has no effect, since selecting a directory includes >> everything inside its hierarchy. Anytime you want to commit some-but- >> not-all resource in a hierarchy, there is no choice but to cmd-click >> each one individually. Essentially, Versions currently caters well >> to opt-in selection, but not opt-out deselection. In many cases, it >> becomes trivial to add one more resource, but disproportionately >> difficult to exclude one resource. This is the part that's painful >> for large commits. Does that make more sense? >> >> I realize that with flat hierarchies this is virtually a non-issue, >> but please don't assume that everyone can or does structure their >> projects that way. :-) >> >> - Quinn >> >> >> On Nov 19, 2009, at 7:57 AM, Hardy Macia wrote: >> >>> >>> I've only done the selective commits by selecting files that I want >>> to commit, not the other way around as you
Re: Feature Requests
Quin, I get your point. Why not expand your hierarchy select them all with shift click and deselect the folders and the items you wish to exclude with command click? - Marijn On Nov 19, 2009, at 5:18 PM, Quinn Taylor wrote: > I think you're misunderstanding my point. I'm not extolling the > virtues of Eclipse, I also find it annoying in many ways, but for > large Java projects, it does redeem itself. (FWIW, configuring a > project is IMO the absolute worst part of Eclipse. Once you get past > that, working with it isn't half bad, especially for an all-Java > app.) I was only making a point of how the SVN plugins act in > Eclipse to provide a concrete example. > > The approach you specify doesn't work in many situations. Imagine > you have a Java package hierarchy with classes scattered up and down > 6+ levels of it. If you don't want to commit everything in the > hierarchy, selecting everything and deselecting resources not to > commit has no effect, since selecting a directory includes > everything inside its hierarchy. Anytime you want to commit some-but- > not-all resource in a hierarchy, there is no choice but to cmd-click > each one individually. Essentially, Versions currently caters well > to opt-in selection, but not opt-out deselection. In many cases, it > becomes trivial to add one more resource, but disproportionately > difficult to exclude one resource. This is the part that's painful > for large commits. Does that make more sense? > > I realize that with flat hierarchies this is virtually a non-issue, > but please don't assume that everyone can or does structure their > projects that way. :-) > > - Quinn > > > On Nov 19, 2009, at 7:57 AM, Hardy Macia wrote: > >> >> I've only done the selective commits by selecting files that I want >> to commit, not the other way around as you are suggesting, but >> isn't what you want to do just... >> >> Show changed files, select all, cmd-click the file/files you don't >> want to commit? >> >> I've only used Eclipse once for a small project, but I found it >> extremely annoying to use. >> >> -Hardy >> >> On Nov 19, 2009, at 10:50 AM, Quinn Taylor wrote: >> >>> It's a matter of workflow preference. Yes, you can select files >>> and folders in the main GUI before committing — command-clicking >>> etc. obviously works, but just because something is possible >>> doesn't mean that's the only way anyone would/should ever want to >>> do it. (Exhibit A: Windows) However, it can be a pain for deeply- >>> nested hierarchies and excluding that one file that shouldn't be >>> committed yet. The SVN plugins for Eclipse provide checkboxes in >>> the commit window, and they can be incredibly handy when you need >>> them. However, I generally only use them for *removing* files from >>> the commit, so perhaps an unobtrusive button in the bottom left >>> corner (which allows you to exclude 1 or more selected entries >>> from the commit, without changing the selection in the main >>> window) would be a good compromise? >>> >>> - Quinn >>> >>> On Nov 19, 2009, at 7:38 AM, Hardy Macia wrote: >>> I'm always submitting a few files from versions so that I can submit related file changes together. Cmd-click/shft-click on the files to select the ones you want to submit and submit them. I think checkboxes would get in the way. - Hardy > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
I think you're misunderstanding my point. I'm not extolling the virtues of Eclipse, I also find it annoying in many ways, but for large Java projects, it does redeem itself. (FWIW, configuring a project is IMO the absolute worst part of Eclipse. Once you get past that, working with it isn't half bad, especially for an all-Java app.) I was only making a point of how the SVN plugins act in Eclipse to provide a concrete example. The approach you specify doesn't work in many situations. Imagine you have a Java package hierarchy with classes scattered up and down 6+ levels of it. If you don't want to commit everything in the hierarchy, selecting everything and deselecting resources not to commit has no effect, since selecting a directory includes everything inside its hierarchy. Anytime you want to commit some-but-not-all resource in a hierarchy, there is no choice but to cmd-click each one individually. Essentially, Versions currently caters well to opt-in selection, but not opt-out deselection. In many cases, it becomes trivial to add one more resource, but disproportionately difficult to exclude one resource. This is the part that's painful for large commits. Does that make more sense? I realize that with flat hierarchies this is virtually a non-issue, but please don't assume that everyone can or does structure their projects that way. :-) - Quinn On Nov 19, 2009, at 7:57 AM, Hardy Macia wrote: > > I've only done the selective commits by selecting files that I want to > commit, not the other way around as you are suggesting, but isn't what you > want to do just... > > Show changed files, select all, cmd-click the file/files you don't want to > commit? > > I've only used Eclipse once for a small project, but I found it extremely > annoying to use. > > -Hardy > > On Nov 19, 2009, at 10:50 AM, Quinn Taylor wrote: > >> It's a matter of workflow preference. Yes, you can select files and folders >> in the main GUI before committing — command-clicking etc. obviously works, >> but just because something is possible doesn't mean that's the only way >> anyone would/should ever want to do it. (Exhibit A: Windows) However, it can >> be a pain for deeply-nested hierarchies and excluding that one file that >> shouldn't be committed yet. The SVN plugins for Eclipse provide checkboxes >> in the commit window, and they can be incredibly handy when you need them. >> However, I generally only use them for *removing* files from the commit, so >> perhaps an unobtrusive button in the bottom left corner (which allows you to >> exclude 1 or more selected entries from the commit, without changing the >> selection in the main window) would be a good compromise? >> >> - Quinn >> >> On Nov 19, 2009, at 7:38 AM, Hardy Macia wrote: >> >>> >>> I'm always submitting a few files from versions so that I can submit >>> related file changes together. >>> >>> Cmd-click/shft-click on the files to select the ones you want to submit and >>> submit them. I think checkboxes would get in the way. >>> >>> - Hardy smime.p7s Description: S/MIME cryptographic signature
Re: Feature Requests
I've only done the selective commits by selecting files that I want to commit, not the other way around as you are suggesting, but isn't what you want to do just... Show changed files, select all, cmd-click the file/files you don't want to commit? I've only used Eclipse once for a small project, but I found it extremely annoying to use. -Hardy On Nov 19, 2009, at 10:50 AM, Quinn Taylor wrote: > It's a matter of workflow preference. Yes, you can select files and folders > in the main GUI before committing — command-clicking etc. obviously works, > but just because something is possible doesn't mean that's the only way > anyone would/should ever want to do it. (Exhibit A: Windows) However, it can > be a pain for deeply-nested hierarchies and excluding that one file that > shouldn't be committed yet. The SVN plugins for Eclipse provide checkboxes in > the commit window, and they can be incredibly handy when you need them. > However, I generally only use them for *removing* files from the commit, so > perhaps an unobtrusive button in the bottom left corner (which allows you to > exclude 1 or more selected entries from the commit, without changing the > selection in the main window) would be a good compromise? > > - Quinn > > On Nov 19, 2009, at 7:38 AM, Hardy Macia wrote: > >> >> I'm always submitting a few files from versions so that I can submit related >> file changes together. >> >> Cmd-click/shft-click on the files to select the ones you want to submit and >> submit them. I think checkboxes would get in the way. >> >> - Hardy >> >> On Nov 19, 2009, at 10:35 AM, tom.dev...@googlemail.com wrote: >> >>> >>> @Tomo >>> >>> "I personally often work on more than one thing on a project, and >>> when >>> I want to commit, I would like to be able to commit different things >>> seperately. " >>> >>> Could you not just selected individual files to commit in the list >>> view or am I missing something? >>> >>> "Versions should also know that I have new files and offer me to add >>> them automatically before commiting" >>> >>> Totally agree with this tho :) >>> >>> >>> >>> On Nov 17, 2:11 pm, Ryan wrote: I have to agree with Asbjørn on both counts. On Nov 16, 2:43 pm, Asbjørn Ulsberg wrote: > On Mon, 16 Nov 2009 16:35:54 +0100, Ray wrote: >> I agree with the commit UI changes, but this is a workflow issue. > For some use cases, I agree this is a workflow issue, but for others it > isn't. You might want to partially commit your entire working directory > because you've been working on several different tasks at once and only > want files related to task X commited, but not those related to task Y. > In such use cases, a checkbox beside each modified file would be neat. >> I keep a skeleton default config file versioned, and the actual config >> file ignored. Then you never have to worry about committing this file. > I do the same thing. Works like a charm. That is, until you change the > skeleton file and forget to update the unversioned config file. ;) > -- > Asbjørn Ulsberg -=|=- asbj...@ulsberg.no > «He's a loathsome offensive brute, yet I can't look away» >> >> >> >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
It's a matter of workflow preference. Yes, you can select files and folders in the main GUI before committing — command-clicking etc. obviously works, but just because something is possible doesn't mean that's the only way anyone would/should ever want to do it. (Exhibit A: Windows) However, it can be a pain for deeply-nested hierarchies and excluding that one file that shouldn't be committed yet. The SVN plugins for Eclipse provide checkboxes in the commit window, and they can be incredibly handy when you need them. However, I generally only use them for *removing* files from the commit, so perhaps an unobtrusive button in the bottom left corner (which allows you to exclude 1 or more selected entries from the commit, without changing the selection in the main window) would be a good compromise? - Quinn On Nov 19, 2009, at 7:38 AM, Hardy Macia wrote: > > I'm always submitting a few files from versions so that I can submit related > file changes together. > > Cmd-click/shft-click on the files to select the ones you want to submit and > submit them. I think checkboxes would get in the way. > > - Hardy > > On Nov 19, 2009, at 10:35 AM, tom.dev...@googlemail.com wrote: > >> >> @Tomo >> >> "I personally often work on more than one thing on a project, and >> when >> I want to commit, I would like to be able to commit different things >> seperately. " >> >> Could you not just selected individual files to commit in the list >> view or am I missing something? >> >> "Versions should also know that I have new files and offer me to add >> them automatically before commiting" >> >> Totally agree with this tho :) >> >> >> >> On Nov 17, 2:11 pm, Ryan wrote: >>> I have to agree with Asbjørn on both counts. >>> >>> On Nov 16, 2:43 pm, Asbjørn Ulsberg wrote: >>> >>> >>> On Mon, 16 Nov 2009 16:35:54 +0100, Ray wrote: > I agree with the commit UI changes, but this is a workflow issue. >>> For some use cases, I agree this is a workflow issue, but for others it isn't. You might want to partially commit your entire working directory because you've been working on several different tasks at once and only want files related to task X commited, but not those related to task Y. >>> In such use cases, a checkbox beside each modified file would be neat. >>> > I keep a skeleton default config file versioned, and the actual config > file ignored. Then you never have to worry about committing this file. >>> I do the same thing. Works like a charm. That is, until you change the skeleton file and forget to update the unversioned config file. ;) >>> -- Asbjørn Ulsberg -=|=- asbj...@ulsberg.no «He's a loathsome offensive brute, yet I can't look away» >>> > > > --~--~-~--~~~---~--~~ > You received this message because you are subscribed to the Google Groups > "Versions" group. > To post to this group, send email to versions@googlegroups.com > To unsubscribe from this group, send email to > versions+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/versions?hl=en > -~--~~~~--~~--~--~--- > smime.p7s Description: S/MIME cryptographic signature
Re: Feature Requests
I'm always submitting a few files from versions so that I can submit related file changes together. Cmd-click/shft-click on the files to select the ones you want to submit and submit them. I think checkboxes would get in the way. - Hardy On Nov 19, 2009, at 10:35 AM, tom.dev...@googlemail.com wrote: > > @Tomo > > "I personally often work on more than one thing on a project, and > when > I want to commit, I would like to be able to commit different things > seperately. " > > Could you not just selected individual files to commit in the list > view or am I missing something? > > "Versions should also know that I have new files and offer me to add > them automatically before commiting" > > Totally agree with this tho :) > > > > On Nov 17, 2:11 pm, Ryan wrote: >> I have to agree with Asbjørn on both counts. >> >> On Nov 16, 2:43 pm, Asbjørn Ulsberg wrote: >> >> >> >>> On Mon, 16 Nov 2009 16:35:54 +0100, Ray wrote: I agree with the commit UI changes, but this is a workflow issue. >> >>> For some use cases, I agree this is a workflow issue, but for others it >>> isn't. You might want to partially commit your entire working directory >>> because you've been working on several different tasks at once and only >>> want files related to task X commited, but not those related to task Y. >> >>> In such use cases, a checkbox beside each modified file would be neat. >> I keep a skeleton default config file versioned, and the actual config file ignored. Then you never have to worry about committing this file. >> >>> I do the same thing. Works like a charm. That is, until you change the >>> skeleton file and forget to update the unversioned config file. ;) >> >>> -- >>> Asbjørn Ulsberg -=|=- asbj...@ulsberg.no >>> «He's a loathsome offensive brute, yet I can't look away» > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Feature Requests
@Tomo "I personally often work on more than one thing on a project, and when I want to commit, I would like to be able to commit different things seperately. " Could you not just selected individual files to commit in the list view or am I missing something? "Versions should also know that I have new files and offer me to add them automatically before commiting" Totally agree with this tho :) On Nov 17, 2:11 pm, Ryan wrote: > I have to agree with Asbjørn on both counts. > > On Nov 16, 2:43 pm, Asbjørn Ulsberg wrote: > > > > > On Mon, 16 Nov 2009 16:35:54 +0100, Ray wrote: > > > I agree with the commit UI changes, but this is a workflow issue. > > > For some use cases, I agree this is a workflow issue, but for others it > > isn't. You might want to partially commit your entire working directory > > because you've been working on several different tasks at once and only > > want files related to task X commited, but not those related to task Y. > > > In such use cases, a checkbox beside each modified file would be neat. > > > > I keep a skeleton default config file versioned, and the actual config > > > file ignored. Then you never have to worry about committing this file. > > > I do the same thing. Works like a charm. That is, until you change the > > skeleton file and forget to update the unversioned config file. ;) > > > -- > > Asbjørn Ulsberg -=|=- asbj...@ulsberg.no > > «He's a loathsome offensive brute, yet I can't look away» --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Versions unusable because too many crashes
Hi Dirk, thanks for the fast reply this is what I get from svn status -u: svn: In file '/SourceCache/subversion/subversion-35/subversion/ subversion/libsvn_ra_svn/marshal.c' line 486: assertion failed (opt || cstr) Abort trap doesn't look healthy to me.. right? good luck! On Nov 19, 2:29 pm, Dirk Stoop wrote: > Hi Tim, > > First of all, sorry for the trouble. > > Could you try entering the following command in a Terminal window, > after navigating to your working copy? > > svn status -u > > Please let me know if you see anything abnormal in the output. > > Thanks, > - Dirk > > the Versions team > > On Nov 19, 2:17 pm, tim wrote: > > > I hope this might be of some help: > > > I have the same annoying problem: > > Versions starts up, shows me the "send recent crash reports?" dialog > > " Versions has crashed or was terminated abnormally 14 times in the > > recent past. Please send the anonymous crash reports to help us fix > > the problem(s)." > > If there is a network connection, Versions crashes immediately and OSX > > tells me it wants to send a crash report to Apple. > > > This issue first occurred after I did a "rename" command on a folder. > > After the rename, the original folder was still there and I had errors > > showing up when updating / committing the project. (don't remember > > exactly what the errors were.. something about the folder being > > unversioned) So I tried to delete this folder but Versions couldn't > > and force delete also didn't work. > > Then, I deleted the folder on my windows machine, (where I also have a > > working copy of this project) using Tortoise. > > After I did this, every time Versions starts up and has a network > > connection, it crashes immediately. > > > I first "fixed" the problem by turning off my network connection, > > start Versions (no crash) and switch off Badges in preferences. > > Now, when I just click the bookmark with the rename / delete trouble, > > I notice Versions is trying to connect to the SVN server here on my > > local network, then crashes again! > > Which means that all my other bookmarks are OK (if Badges is > > unchecked) but this one particular bookmark is useless. > > > SPECS: > > The repository for this bookmark is on a windows machine on my local > > network running svnserve 1.5.1 r32289. > > I use SVN without SSH to talk to it. > > > versions 1.0.6 - Build 71 > > Snow Leopard 10.6.2 build 10C540 > > svn version 1.6.5 (r38866) > > > I would love to provide more information if needed! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Versions unusable because too many crashes
Hi Tim, First of all, sorry for the trouble. Could you try entering the following command in a Terminal window, after navigating to your working copy? svn status -u Please let me know if you see anything abnormal in the output. Thanks, - Dirk the Versions team On Nov 19, 2:17 pm, tim wrote: > I hope this might be of some help: > > I have the same annoying problem: > Versions starts up, shows me the "send recent crash reports?" dialog > " Versions has crashed or was terminated abnormally 14 times in the > recent past. Please send the anonymous crash reports to help us fix > the problem(s)." > If there is a network connection, Versions crashes immediately and OSX > tells me it wants to send a crash report to Apple. > > This issue first occurred after I did a "rename" command on a folder. > After the rename, the original folder was still there and I had errors > showing up when updating / committing the project. (don't remember > exactly what the errors were.. something about the folder being > unversioned) So I tried to delete this folder but Versions couldn't > and force delete also didn't work. > Then, I deleted the folder on my windows machine, (where I also have a > working copy of this project) using Tortoise. > After I did this, every time Versions starts up and has a network > connection, it crashes immediately. > > I first "fixed" the problem by turning off my network connection, > start Versions (no crash) and switch off Badges in preferences. > Now, when I just click the bookmark with the rename / delete trouble, > I notice Versions is trying to connect to the SVN server here on my > local network, then crashes again! > Which means that all my other bookmarks are OK (if Badges is > unchecked) but this one particular bookmark is useless. > > SPECS: > The repository for this bookmark is on a windows machine on my local > network running svnserve 1.5.1 r32289. > I use SVN without SSH to talk to it. > > versions 1.0.6 - Build 71 > Snow Leopard 10.6.2 build 10C540 > svn version 1.6.5 (r38866) > > I would love to provide more information if needed! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Versions unusable because too many crashes
I hope this might be of some help: I have the same annoying problem: Versions starts up, shows me the "send recent crash reports?" dialog " Versions has crashed or was terminated abnormally 14 times in the recent past. Please send the anonymous crash reports to help us fix the problem(s)." If there is a network connection, Versions crashes immediately and OSX tells me it wants to send a crash report to Apple. This issue first occurred after I did a "rename" command on a folder. After the rename, the original folder was still there and I had errors showing up when updating / committing the project. (don't remember exactly what the errors were.. something about the folder being unversioned) So I tried to delete this folder but Versions couldn't and force delete also didn't work. Then, I deleted the folder on my windows machine, (where I also have a working copy of this project) using Tortoise. After I did this, every time Versions starts up and has a network connection, it crashes immediately. I first "fixed" the problem by turning off my network connection, start Versions (no crash) and switch off Badges in preferences. Now, when I just click the bookmark with the rename / delete trouble, I notice Versions is trying to connect to the SVN server here on my local network, then crashes again! Which means that all my other bookmarks are OK (if Badges is unchecked) but this one particular bookmark is useless. SPECS: The repository for this bookmark is on a windows machine on my local network running svnserve 1.5.1 r32289. I use SVN without SSH to talk to it. versions 1.0.6 - Build 71 Snow Leopard 10.6.2 build 10C540 svn version 1.6.5 (r38866) I would love to provide more information if needed! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
