Re: Subversion 1.7 support?
I'd like to second Alex's email. Now that Subversion 1.7 is what MacPorts provides, a Mac Subversion client really must support 1.7. I still have Versions installed, but haven't used it in a month (since I installed Lion on my machine). Really hoping that this support can arrive soon. Have to tell my colleagues not to buy Versions for now. On Wednesday, July 11, 2012 3:43:00 AM UTC-5, Alex Seeholzer wrote: > > Thanks for your opinion on this. I believe you when you're saying you're > working your asses off. Still, I want to stress that 1.7 support should be > one of the first things to be released for a product that costs a whooping > 59$. > We had to upgrade to 1.7 here and now Versions is basically useless for > me. And, its not that 1.7 has just come out - its been about 9 months. > > Still hoping for 1.7 support, > Alex > > Am Sonntag, 27. Mai 2012 14:20:01 UTC+2 schrieb dlpasco: >> >> We bought this software to continue updating it and make it even greater >> than it already is. >> >> Unfortunately, disclosing our product roadmap is not an option. Jack is >> in the unenviable position of being the public face for this product - >> please at least divert your frustration to me personally, because he is >> just conveying the message that our team members have all internally agreed >> to stand by: we give a damn what people think, our product group is very >> busy, and we can't talk about when we'll release products or what will be >> in the those releases until they have shipped. >> >> If people are upset about that, it's understandable. All that I can say >> is, we didn't acquire this product to kill it or sit on it. >> >> The gist of this is as follows: >> >> * We can't miss a deadline we don't announce (on at least one product, we >> would have missed our proposed deadline multiple times if we'd kept telling >> people when we planned to ship. Unfortunately, really producing a polished >> product takes a lot of time, and we agreed internally that we'd rather take >> longer to make something better than just push something out the door that >> would make people upset). >> * If we don't announce the features in our next planned release, we can't >> get flamed for postponing support for that feature in the release if it >> looks like it's not ready to make it into the build yet). >> * Our competitors (and there are many out there) - can't jump the gun on >> us if we don't announce an upcoming feature before it goes live. >> >> All three of these factors are important, and the last one may only be >> important to us, but it's a critical one: our product team is young and >> totally buried working on applications - if we lose market share simply >> because we announce something before it's ready, and someone else is >> capable of responding to the announcement before we ship, it's going to >> really hurt our ability to even break even on what we're working on - which >> means that it will become even harder for our team to ship great updates to >> these apps. >> >> My personal focus for almost the last year has been on putting absolutely >> all of my energy into our product team. These apps are large, complex, >> great things, and we're committed to doing great work on everything we >> ship. Since our product team currently consists of about five full time >> developers and four full time designers, and we have taken on five >> different applications. Moving forward with these apps *and* doing a great >> job on them takes time. >> >> Our company is investing heavily in the product group, currently at a net >> loss. Hopefully, at some point in the future we will at least break even on >> our work. At the present, please try to take the following points to heart: >> >> * We are crazily in love with our apps >> * We are working our butts off >> * We have already turned down offers to acquire our company, as well as >> offers to acquire individual products, because we want to see these apps >> *ship* and we want them to be amazing. >> * We are absolutely not sitting on these apps and happily collecting >> revenue from them - we're using the revenue to pay for the work our product >> team is doing and our company is sinking considerably more than those apps >> are making into the product group in order to pay for the other people that >> the direct revenue doesn't cover. >> >> At this point, as I've told Jack (who has expressed support for our >> stance of silence, but also really been uncomfortable with the fact that it >> doesn't leave him in a very good position on the support front), the only >> thing we can do is shut up and ship something great. Which is what we're >> trying to do. >> >> If we lose customers in the interim, those are lumps we will have to >> take. Hopefully as our apps do ship, they will be compelling enough that >> people will be interested in trying them out. >> >> I wish we were big enough that I could just throw 30 people at the
"Waiting for transactions to finish" on quit
I am having this problem a lot: when I try to quit Versions, it hangs with "Quitting Versions/Waiting for transactions to finish." AFAICT they never finish. There was a bunch of correspondence about this way back in 2008 and 2009, but no resolution. Any chance this will get fixed? -- 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: Copying File/Directory URLs Inside Versions
This is nice, but for some reason Versions always sticks my user id into the URL. So I follow this recipe, but then I always have to edit the "rpgoldman@" out of the url, which is a nuisance On Mar 14, 1:54 pm, Jamie Poitra wrote: > On Mar 14, 11:50 am, "Jack (Black Pixel)" > wrote: > > > Adding this to the Contextual Menu is on the feature request list. > > Good to hear it's not he feature list. :) > > And thanks for the inspector note. I tend to keep it closed but maybe > I'll stop that now. > > Jamie -- 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.
Feature request: copy multiple entries
svn cp applied to multiple files can be very difficult to do at the command line (in particular because in a working copy, it's hard to get only the files you want). It would be a real convenience to do this with a drag and drop GUI, because the display pays attention to svn:ignore, and command-click lets us unselect items we don't want. But Versions refuses to let me copy more than one item at a time. It would be really nice to remove this restriction. cheers, r -- 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.
Possible to NON-recursively commit a directory?
Sometimes I modify the properties on a directory that contains files I have also modified. But I don't want to do this in one changeset --- I simply want to commit the property modifications. Using the command line, this can be done using a depth option. How can I do this in Versions? If it's not possible to do this, I would suggest adding "commit directory properties only" to the context menu when selecting a directory path in the Versions UI. -- 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: non-recursive (immediates) commit
On Oct 11, 12:05 pm, Quinn Taylor wrote: > I don't know of a way to do that in Versions, but I believe that command-line > svn will allow it. Type `svn help commit` in Terminal and look at the --depth > option. I believe that "--depth empty" is the equivalent of "--non-recursive" > (which is now obsolete). No, that doesn't really help. I mean, I appreciate your pointing this out, but I already knew how to do this at the command line (I see that my post did not make that clear). What I was asking about was how to do this from the GUI. If it's not possible to do this from the GUI, that's on the edge between "RFE" and "bug." The reason I say this is like a "bug" is that it's critical to be able to do this (commit a property change without carrying along into the same change set a large number of unrelated file mods), and IMO Versions shouldn't be forcing me to fall back on the command-line for critical functions. Cheers, r -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versi...@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.
non-recursive (immediates) commit
How do I commit mods to only a directory? E.g., if I edit the externals on a directory node, how do I commit just this modification, without picking up modifications in files and subdirectories? Apologies if this is a FAQ... Home > Versions workflow > Browse > Committing changes is skimpy and has no links to more in-depth discussion -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versi...@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: Ignore edit pane
Yes, that will work, but often I have things like "I want to ignore all the files like this one." So I want not to ignore a single file, but to look at the filename and compose a glob (wildcard) pattern from it. On Mar 18, 10:02 am, Quinn Taylor wrote: > An easier way than typing all the filenames to ignore is to right- > click on a resource and select Ignore from the contextual menu that > pops up. Still, that's not to say that a non-modal window wouldn't be > nice to have... > > Quinn > > Sent from my iPod > > On Mar 18, 2010, at 8:19 AM, Robert Goldman wrote: > > > Would it be possible to make the svn:ignore edit pane NOT be pinned in > > front of the versions window? I.e., would it be possible to make it a > > floating modal dialog box? > > > Here's the use case: > > > * Look at the main Versions window and discover filenames that should > > be ignored. > > > * Press edit button under ignore. > > > * Realize that I can't see the filenames and have forgotten some of > > them. :-( > > > If the window floated, I would slide it out of the way, and be able to > > copy filenames from the main versions pane into the ignore edit pane. > > > I'm hoping that this would be a simple matter to change > > > Cheers, > > r -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versi...@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.
Ignore edit pane
Would it be possible to make the svn:ignore edit pane NOT be pinned in front of the versions window? I.e., would it be possible to make it a floating modal dialog box? Here's the use case: * Look at the main Versions window and discover filenames that should be ignored. * Press edit button under ignore. * Realize that I can't see the filenames and have forgotten some of them. :-( If the window floated, I would slide it out of the way, and be able to copy filenames from the main versions pane into the ignore edit pane. I'm hoping that this would be a simple matter to change Cheers, r -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versi...@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.
Window focus oddity
Here's something that seems odd to me. I often press the update button on Versions and then go off to do something else while the update happens. This typically involves going off the current space to a different one where, for example, my email program or my browser lives. What strikes me as odd is that after completing the update, even if there is no dialog box, versions will grab focus, abruptly ripping me out of the application on which I am working, and even pulling me off my current virtual desktop. It seems appropriate for Versions to do this when it needs to pop up a dialog box to warn me that something has not gone well, or in another abnormal case. But if the update goes smoothly, I don't see any reason for Versions to grab focus when it's done. Cheers, r --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Showing/Hiding the Inspector --- menu placement
I opened the inspector in Versions the other day, and afterwards was having the darnedest time figuring out how to get rid of it. I only managed when I accidentally stumbled on "Hide Inspector" in the "File" menu. It never occurred to me that it would be there --- I assumed (I think reasonably) that commands to show or hide a column on the display would appear in the "View" menu. Now I think I can sort of understand the rationale --- you think of "Inspecting" as an operation that would be applied to a file --- but the way this is implemented, since whether or not the inspector is visible is modal (unlike "Show Info," which really *is* a file operation), I'd argue that these commands should be moved to the View menu. Best, R --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Problem with externals that use ssl certificates
I have a working directory, let's call it "wd1," that contains external definitions to a different repository host. That repository host must be reached through ssl, and requires certificates for authentication. I am able to put information in ~/.subversion/servers specifying certificates and certificate passwords for that host. Using that information I am able to update wd1 through the command-line as "svn update". However, I am *not* able to update wd1 through versions. It seems that versions is not able to use the certificate information in ~/.subversions/servers. I also found that if the connection prompted me for a password, it would cause an error in versions. Versions did not seem to be able to intercept the password request. I wasn't terribly bothered by this until recently --- it wasn't that much trouble to update wd1 through the command-line, and most of my interactions with wd1 worked fine. However, I just pulled a new update of versions, and now the behavior is much worse. Versions seems to be polling the repository for this working directory, causing it to repeatedly pop up a dialog window, prompting me for my userid and password for this server. This is very annoying --- it effectively causes versions to lock up, and even if I cancel out of the dialog box, it just comes back later. Is there some way to avoid this behavior? Is there some way I can make versions attend to my .subversion/servers file? I have just checked, and svn update from the command line still works fine. Thanks for any suggestions. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
"open" file doesn't show the file
I have a repository that has files with extension ".asd". These are really text files, and sometimes I would like to look at them direct from the repository (rather than checking out). Unfortunately, when I use the "open" command on these files, something happens, but I never get a window of any application displaying the file. I see that the subversion interaction has succeeded (in the Transcript I see the "Starting Cat Operation" and the "Finished Operation," but I have no idea where the text stream ended up. Would it be possible to add an "open with..." item here? Can anyone explain to me where my text streams are flowing? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
