Re: Can't install demo --- says trial period expired
I guess I'll try SmartSVN ... it seems to work. On Mar 24, 12:57 pm, "john.patrick.gal...@gmail.com" wrote: > Subject says it all ... I want to try this but it won't let me ... how > do I fix this? --~--~-~--~~~---~--~~ 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: Can't install demo --- says trial period expired
Emphasis on "seems to". :-) Versions is much more polished, and I think worth a little patience with any bumps in getting the trial working. There are several SVN clients for OS X, but very few that work like a true Mac app. I suppose it really depends on what's most important to you, but you might try giving it another shot. Did you previously install a demo version and let the trial period expire, or might someone else have done so? That could explain why it won't load now. You might try it on another Mac if you have access to one and see if you love the app before giving up. - Quinn On Mar 30, 2009, at 8:20 AM, john.patrick.gal...@gmail.com wrote: I guess I'll try SmartSVN ... it seems to work. On Mar 24, 12:57 pm, "john.patrick.gal...@gmail.com" wrote: Subject says it all ... I want to try this but it won't let me ... how do I fix this? --~--~-~--~~~---~--~~ 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: Can't install demo --- says trial period expired
It may have been previously installed as I inherited this Mac. Don't have the time/patience to find another machine. On Mar 30, 11:53 am, Quinn Taylor wrote: > Emphasis on "seems to". :-) Versions is much more polished, and I > think worth a little patience with any bumps in getting the trial > working. There are several SVN clients for OS X, but very few that > work like a true Mac app. I suppose it really depends on what's most > important to you, but you might try giving it another shot. > > Did you previously install a demo version and let the trial period > expire, or might someone else have done so? That could explain why it > won't load now. You might try it on another Mac if you have access to > one and see if you love the app before giving up. > > - Quinn > > On Mar 30, 2009, at 8:20 AM, john.patrick.gal...@gmail.com wrote: > > > > > I guess I'll try SmartSVN ... it seems to work. > > > On Mar 24, 12:57 pm, "john.patrick.gal...@gmail.com" > > wrote: > >> Subject says it all ... I want to try this but it won't let me ... > >> how > >> do I fix this? > > > > > > smime.p7s > 3KViewDownload --~--~-~--~~~---~--~~ 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: Subversion 1.6
On 30 Mar, 04:06, Quinn Taylor wrote: > That said, the "special" thing about the built-in SVN libraries is > that they are version 1.4.4 only. In your valiant effor to clarify things, this statement is very imprecise. It's true that MacOSX ships with the 1.4.4 libraries, but those libraries are not "built-in" into anything and nothing prevents the user to upgrade them. In fact the XCode SDK states explicitly (see http://developer.apple.com/tools/subversionxcode.html) that it was designed to work with 1.5.x and you can find on the developer forums the procedure to upgrade. > Since Versions is designed to > support 1.5.x as well, and can't count on users having 1.5.x > installed, the logical choice is to bundle the necessary library > internally. By the same token, for someone like Ganesh who has > replaced the built-in 1.4.4 tools with the 1.5.6 tools, Versions also > shouldn't count on users having 1.4.4 installed, so it's also bundled > internally. Similarly, although using 1.6.x should "just work", if > anything in Versions were incompatible with or buggy under a newer > release of SVN, it wouldn't be "safe" for them to allows users to > dynamically link to whatever is installed in /usr/lib, or /opt/ > subversion, or wherever. If it's safe for XCode, why wouldn't it be safe for Versions? Really I don't get it. We are not talking of a tool for dumb end users. I am a programmer with 20+ years of experience, I know that if I upgrade there is a risk of incompatibility. I won't blame the programmers of Versions if it happen. But I do blame the programmers of Versions if they don't let me try simply because they are afraid of user complaints. Especially since it is a feature that de facto is already implemented! Versions is shipped with two bundles, namely SA146.bundle and SA154.bundle. I don't know the details, but I'm pretty sure that if I put symbolic links into one of those bundles, everything will work just nice. > Versions already checks the version of the command-line binaries in / > usr/bin for compatibility to help minimize conflicts and be a good > citizen, for which the devs are to be commended. I agree that it would > be nice if there were an easier process for end users to update the > 1.4.x and 1.5.x libraries bundled inside Versions. It's not highest on > my priority list, since the minor point releases generally fix fairly > minor bugs and don't introduce any new backwards-incompatible > functionality. There are many other points of usability and polish on > which I place higher value, although I'll be glad to have a newer > bundled SVN as well. I don't need, nor request to update the libraries shipped with Versions. > Perhaps if the preference to point to a custom library location were > unexposed in the UI and had to be set in Terminal using the `defaults` > command, it would be self-evident that if you change it, you get what > you get, and don't blame the developers. Even so, I think it would be > difficult to make it work in all cases, since the devs wouldn't be > able to link against every possible library at build time, and you > wouldn't want them to since it could have an adverse effect on binary > size and load time. I'll trust the devs to decide whether such an > approach would even work, since they know their code. :-) I think that providing an "hidden" feature is kind of stupid. Versions already warns you about possible incompatibility between 1.4.6 and 1.5.4. Just add another warning. If the user wants to shoot himself on the foot, just let him. Just my opinion, Ganesh --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Duplication
Hey guys! I'm a new user of vectors (still testing it demo version), an I found some troubles working whith a windows network. My files that contains accent have automaticaly created a revision, generated in my computer (macbook), when I made the checkout or the update command in my folders. When I do the commit, it has created two files whith the same name in the server too (windows server). Does anyone knows how can I fix it? Best regards. --~--~-~--~~~---~--~~ 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: Recursive Add
One of the greatest features in TortoiseSVN on Windows is the ability to choose "Add" on a folder that already exists in the repository which will dig down and find any files or folders that are not under version control and add them for you. This is a HUGE timesaver, especially if you have added a bunch of folders and files in various subfolders. You can just hit the top level and click Add and it will find and add any subfolders and files that have not been added. Digging down yourself manually takes a lot of time. Please consider adding this extremely useful feature. --~--~-~--~~~---~--~~ 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 Request: Recursive Add
I won't say it couldn't be a useful feature, but I think the different nature of Versions makes this less of an issue. Since TortoiseSVN is primarily a context-menu-based tool, it makes sense to eliminate lots of file system "yo-yo" browsing. Since versions is an application, I find the easiest way to add as-yet unversioned contents of a directory is to toggle from "All" to "Changed". Anything that hasn't yet been added will show up with a question mark. (This works best if any modified resources have already been committed.) I do realize this involves command-clicking each entry and clicking Add, but it's a lot less work than filesystem browsing. Also, when adding files/ directories, I tend to err on the side of caution — I don't generally add everything that hasn't been yet, but instead specifically add what I want to add. Maybe that's different than your workflow, so the feature could still be more useful to you than to me. - Quinn On Mar 30, 2009, at 11:46 AM, Steven Sacks wrote: One of the greatest features in TortoiseSVN on Windows is the ability to choose "Add" on a folder that already exists in the repository which will dig down and find any files or folders that are not under version control and add them for you. This is a HUGE timesaver, especially if you have added a bunch of folders and files in various subfolders. You can just hit the top level and click Add and it will find and add any subfolders and files that have not been added. Digging down yourself manually takes a lot of time. Please consider adding this extremely useful feature. --~--~-~--~~~---~--~~ 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: Subversion 1.6
On Mar 30, 2009, at 2:09 PM, Alberto Ganesh Barbati wrote: On 30 Mar, 04:06, Quinn Taylor wrote: That said, the "special" thing about the built-in SVN libraries is that they are version 1.4.4 only. In your valiant effor to clarify things, this statement is very imprecise. It's true that MacOSX ships with the 1.4.4 libraries, but those libraries are not "built-in" into anything and nothing prevents the user to upgrade them. In fact the XCode SDK states explicitly (see http://developer.apple.com/tools/subversionxcode.html) that it was designed to work with 1.5.x and you can find on the developer forums the procedure to upgrade. I wasn't trying to start a dispute about it, but be aware that many people internal to Apple often refer to "built-in" tools. Of course this is meant to refer to the stock tools, the default, the ones that ship with the system, the ones that can affect the entire system if modified, ones that require admin access to change. I apologize if this caused any confusion, but I didn't mean they were built into anything in particular, which is why I specifically listed the locations where they are installed. (As a note, I can't find anywhere on that link that backs up your claim. Midway down the page, it states that Xcode 1.5+ has support for Subversion built-in, but nothing about which version of Xcode. That article was last update at the end of 2005, right when SVN 1.3 was released, which is why the instructions detail installing SVN 1.2.3.) Since Versions is designed to support 1.5.x as well, and can't count on users having 1.5.x installed, the logical choice is to bundle the necessary library internally. By the same token, for someone like Ganesh who has replaced the built-in 1.4.4 tools with the 1.5.6 tools, Versions also shouldn't count on users having 1.4.4 installed, so it's also bundled internally. Similarly, although using 1.6.x should "just work", if anything in Versions were incompatible with or buggy under a newer release of SVN, it wouldn't be "safe" for them to allows users to dynamically link to whatever is installed in /usr/lib, or /opt/ subversion, or wherever. If it's safe for XCode, why wouldn't it be safe for Versions? Really I don't get it. We are not talking of a tool for dumb end users. I am a programmer with 20+ years of experience, I know that if I upgrade there is a risk of incompatibility. I won't blame the programmers of Versions if it happen. But I do blame the programmers of Versions if they don't let me try simply because they are afraid of user complaints. Especially since it is a feature that de facto is already implemented! Versions is shipped with two bundles, namely SA146.bundle and SA154.bundle. I don't know the details, but I'm pretty sure that if I put symbolic links into one of those bundles, everything will work just nice. No offense, but that's a flawed premise. Compatibility of one application does not imply compatibility of all applications. I know the Subversion team takes great pains to ensure maximum compatibility, but sometimes bug fixes can break expected behavior, and my experience is that allowing one's software to knowingly operate in untested situations is dangerous. Xcode has a vastly larger development and test team than does Versions, and it's an entirely different beast. If the Versions devs were to state that their app is designed to work with SVN 1.6.x and provide instructions to upgrade, then one can make the case that it should be safe. Given the recurrent nature of several other feature requests and bug reports, I'm sure the devs are more occupied with things that will are more important to a greater number of users. I made no assumptions (or insults) about your skill or experience. It's true that Subversion isn't designed for "dumb end users" — it is generally assumed that people who are dealing with Subversion have a higher level of expertise. However, many of the questions on this forum indicate that many Versions users are still relative novices when it comes to the ins and outs of Subversion. (Heck, I'm an experienced programmer, and I still do pretty much all my work in trunk! I've been waiting to deal with branching and merging until I can move all my development to 1.5. For personal projects, I simply haven't had the need to branch.) Versions already checks the version of the command-line binaries in / usr/bin for compatibility to help minimize conflicts and be a good citizen, for which the devs are to be commended. I agree that it would be nice if there were an easier process for end users to update the 1.4.x and 1.5.x libraries bundled inside Versions. It's not highest on my priority list, since the minor point releases generally fix fairly minor bugs and don't introduce any new backwards-incompatible functionality. There are many other points of usability and polish on which I place higher value, although I'll be glad to have a
Re: Subversion 1.6
(As a note, I can't find anywhere on that link that backs up your claim. Midway down the page, it states that Xcode 1.5+ has support for Subversion built-in, but nothing about which version of Xcode. That article was last update at the end of 2005, right when SVN 1.3 was released, which is why the instructions detail installing SVN 1.2.3.) (Of course I meant "nothing about which version of Subversion.") smime.p7s Description: S/MIME cryptographic signature
Re: Problem with umlaut characters like ö,ä,ü
I have exactly the same problem working whith both windows and Mac in a server based in windows server 2003. Now I have files and folders duplicated whith the same name in my macbook and in the server... Is there anything I can do to fix it? Regards --~--~-~--~~~---~--~~ 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 with umlaut characters like ö,ä,ü
I forgot to say, I'm working in brasilian portuguese (á; ã; ç; õ) On 4 mar, 11:19, ruluk7 wrote: > Is there any chance that there will ever be an update addressing this > problem? Even if it's not Versions fault, Versions should be able to > handle that correctly... At least other SVN clients do (SmartSVN). > > regards --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
