Re: SVN export just the changed files from tags
Hi, On 7 Jan., 17:41, Barney suzka...@gmail.com wrote: Is it possible to export to just export the changed files between two tags? no. This and a bit more is one of the most wanted features for versions (extended diff and merge support) I guess. But terminal is your friend. You can only get a diff (shows you the differences for each changed file). with --summarize option you get the action (M odified D eleted A dded) and the path for the file. You can pipe this output into a textfile and further more you play around with awk for more processing. I guess, the TortoiseSVN guys do something similar. Hold the list (your export file), iterate, read the change action and use the URL to get the file. What do you have in mind? Normally, you don't need those files, because you can use the merge and have a dry-run option for it. ~ Markus Here is some documentation I found about how to do this with TortoiseSVN: * open the repository browser, browse to tag1.0, right-click, choose mark for comparison * browse to tag1.1, right-click, choose compare urls * in the file diff dialog, select all files/folders that changed between the tags (Ctrl+A) * right-click, choose export to... --~--~-~--~~~---~--~~ 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: FR: forbit to commit into a tag
Please don't, perhaps I need to change an externals definition in my tags folder to point to some other svn repo tag, I need to have commit access to that folder in that case. Kind regards, Marijn On Feb 17, 2009, at 9:21 AM, mguske wrote: Hi, please forbid to commit into a ./tags-path if the repository layout is the basic with trunk/branches/tags. I know, those directories are only a convention, but before it accidentally happen. Thanks, ~ Markus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
FR: search field for browse window
Please add an search field to add a file pattern (or more sophisticated a spotlight field for the browse view) to shrink the file list. For All and Changed - View. Even if you have a lot of files with a lot of directories, it is very time consuming, to navigate to a file for comparison purposes. Thx, ~ Markus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
FR: alternative view for Browse view needed
Hi, please add a plan - list view as an alternative for the current tree- view only view. Thx, ~ Markus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
FR: make the Changed items-list in Browse view selectable...
Hi, it would be great, if you add a feature, to select what kind of Changed items the user sees. Default: all selectable: added, modified, unversioned, deleted Thx, ~ Markus --~--~-~--~~~---~--~~ 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: FR: forbit to commit into a tag
Hi, On 17 Feb., 17:18, Quinn Taylor quinntay...@mac.com wrote: Agreed, this is something that should be done in the repository itself (as a pre-commit hook) sometimes you're not able to place a hook into the repository - e.g. in large scaled projects, when you work as a consultant. And: customers will not always listen ;-), but that's o.k. or by educating users. The same, you can only try to teach, every day and your colleagues learn each day, more and more. But version control can still be a little bit, let me say: difficult. Even if it were implemented in Versions (which is a bad idea) the user could just switch to Terminal or another client and commit to /tags, Right, but most of the time, the users won't use the shell - that could sometimes be your luck. Let me say, they are afraid of it, like a developer branch and so on. so *every* client would have to forbid this. Save yourself the headache, take the time to learn about pre-commit hooks and disallow any overwriting of a tag. I agree, but sometimes you doesn't have the admin priviledges granted and this feature could also save your day. I requested this feature based on own experiences. Finally, you're right, best solution is to prevent this via hook- scripts. But this convention supporting feature would also be great. ~ Markus - Quinn On Feb 17, 2009, at 3:11 AM, Marijn Huizendveld wrote: Please don't, perhaps I need to change an externals definition in my tags folder to point to some other svn repo tag, I need to have commit access to that folder in that case. Kind regards, Marijn On Feb 17, 2009, at 9:21 AM, mguske wrote: Hi, please forbid to commit into a ./tags-path if the repository layout is the basic with trunk/branches/tags. I know, those directories are only a convention, but before it accidentally happen. Thanks, ~ Markus smime.p7s 3KAnzeigenHerunterladen --~--~-~--~~~---~--~~ 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: remot working copy?
On Feb 11, 2:21 am, patrickk sehmasch...@gmail.com wrote: I know that this question has been answered a couple of times, but so far there doesn´t seem to be a solution. is it possible to work with a remote working copy? our repository and our working copy is on the same external server. so, it´d be fantastic to use versions with that environment, but it doesn´t seem to work. did any solve this problem? are there any workarounds (besides macfuse, expandrive ...)? thanks, patrick If the remote server supports WebDAV you can use that. I've done it for working copies in the past. I don't see why it wouldn't work for a repository also. If you connect via WebDAV the remote volume appears on your Desktop as a mounted volume and you can treat it like any other mounted disk. --~--~-~--~~~---~--~~ 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: FR: forbit to commit into a tag
I understand your quandry, but I can't agree with that approach unless it's strictly optional, off by default, and fairly configurable. It would be nice if SVN could make it easier to forbid committing to tags (perhaps except for a certain group of admin users) on the repository side, maybe even as a default. However, this is a difficult problem—either on client or server—since repository structure varies greatly, and guessing whether or not commits should be allowed is unreliable. For example, some repositories contain multiple projects, and the root level does not always contain trunk/branches/tags as you'd expect. Even if you look down X levels, there is the problem of forbidding access to a directory named tags which has nothing to do with tagged revisions. In practice, this problem is just not that easy to solve... As far as user education, I'm generally not one to use this as a cop- out for honest requests, but it generally works quite well. In your case, if the users are afraid of the Terminal, perhaps you could impress upon them an equal fear of committing to a tag after it has been written. Tell them it will screw up your process. Tell them the repository admin will come banging on their door. Tell them it can affect their bonuses, whatever. ;-) When you give people a strict rule and explain why, it generally works. If they don't understand why, and Versions won't let them commit to tags, they'll end up being confused and frustrated, and potentially more likely to explore other options (not just Terminal, but other GUIs) due to a perception that Versions must be broken. Sorry to be a naysayer, but I think that user education and persistence with the repo admins are the best courses of action. - Quinn On Feb 17, 2009, at 8:51 AM, mguske wrote: I agree, but sometimes you doesn't have the admin priviledges granted and this feature could also save your day. I requested this feature based on own experiences. Finally, you're right, best solution is to prevent this via hook- scripts. But this convention supporting feature would also be great. ~ Markus On Feb 17, 2009, at 3:11 AM, Marijn Huizendveld wrote: Please don't, perhaps I need to change an externals definition in my tags folder to point to some other svn repo tag, I need to have commit access to that folder in that case. Kind regards, Marijn On Feb 17, 2009, at 9:21 AM, mguske wrote: Hi, please forbid to commit into a ./tags-path if the repository layout is the basic with trunk/branches/tags. I know, those directories are only a convention, but before it accidentally happen. Thanks, ~ Markus smime.p7s Description: S/MIME cryptographic signature
Re: FR: Open with... as context menu entry
I definitely second that as I've been meaning to post the same suggestion :) On Feb 16, 2:52 pm, mguske markus.gu...@googlemail.com wrote: Please add an Open with... entry into the context menu for selected items. thx, ~ Markus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Enhancements to Timeline needed
I love the Versions timeline. It's actually the feature that made the choice between Versions and Cornerstone a no-brainer (Cornerstone, amazingly, does not have an equal feature, which was a show-stopper for me). That said, there are a few changes that would make Versions timeline more useful. Thanks for your consideration and a great app! Here are my suggestions in no particular order: * Change tooltip to display full path/name on mouse hover If the pathname is long and the window is not maximized, it is impossible to see the full path or filename without resizing the window. Right now, the tooltip simply says Show changes committed on this revision. * Don't try to DIFF binary files Self explanatory, but I've accidentally clicked on binary files a few times (often because I can't see the full filename as mentioned above). * Add additional contextual menus Right now the contextual menu for each is pretty much worthless (Look Up in Dictionary?). Now, I realize that the listing for each file may not match the working copy revision. But it would still be extremely helpful if the contextual menu for the files had the following options in them: - Open - Open With... - Reveal in Finder - Reveal in Versions Obviously, these should only appear when looking at the timeline for a working copy vs. repository. --~--~-~--~~~---~--~~ 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: Enhancements to Timeline needed
Totally agree! The timeline was my showstopper at Cornerstone. +1 for the enhancements ~ Markus On 18 Feb., 00:17, kiddailey kiddai...@gmail.com wrote: I love the Versions timeline. It's actually the feature that made the choice between Versions and Cornerstone a no-brainer (Cornerstone, amazingly, does not have an equal feature, which was a show-stopper for me). That said, there are a few changes that would make Versions timeline more useful. Thanks for your consideration and a great app! Here are my suggestions in no particular order: * Change tooltip to display full path/name on mouse hover If the pathname is long and the window is not maximized, it is impossible to see the full path or filename without resizing the window. Right now, the tooltip simply says Show changes committed on this revision. * Don't try to DIFF binary files Self explanatory, but I've accidentally clicked on binary files a few times (often because I can't see the full filename as mentioned above). * Add additional contextual menus Right now the contextual menu for each is pretty much worthless (Look Up in Dictionary?). Now, I realize that the listing for each file may not match the working copy revision. But it would still be extremely helpful if the contextual menu for the files had the following options in them: - Open - Open With... - Reveal in Finder - Reveal in Versions Obviously, these should only appear when looking at the timeline for a working copy vs. repository. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
