Re: History in subversion
On Mon, Jun 17, 2013 at 4:09 PM, Olivier Antoine oliviera201...@gmail.com wrote: The common scenario is to have multiple 'projects' under the same repository root, each with their own trunk/branches/tags tree. To be honest, I'm afraid of several projects sharing a same revision numbering. Repository gets bigger and bigger, problems with disk space arise, one project wants to leave the repo, but there is not enough space even to run svn+dump, finally a new repo is created for the project (and the project asks to remove empty revisions ... !). I would prefer to create one repo per project, with one triplet of directories trunk+branches+tags. That's a reasonable choice - and with a repo approaching 80GB I understand the issue although it has not been an actual problem yet. However, other than the sheer size of the dump/filter operation, extracting a portion should be practical even if you renumber as long as you have made tags and use those human-friendly tag names for externals and other specific revisions you need to reference consistently instead of peg revision numbers. You can use hook scripts for that. We sometimes check out source from tags and commit the resulting binaries back - not exactly 'clean' but pragmatically useful - and possible with an appropriate script that allows this exception. Hum ... are these scripts downloadable somewhere, or do we have to write them ... ? Various versions have been posted to forums - and are fairly easy to find with a google search. I'm not sure if there is an 'official' collection anywhere. -- Les Mikesell lesmikes...@gmail.com
Re: History in subversion
Thanks, that's a lot to think about, From: Les Mikesell Taking the history in a copy is what makes svn work and it makes any copied directory functionally usable as a branch or tag. But after that it depends on how you actually use it... As consequence, SVN allows to create branches and tags on a part of the software of the repository, starting at a subdirectory and the copy command can then control/limit the scope of the branch/tag.This can be useful. Now, I only see two uses of the command svn+copy - and two only : - Copy the software of the repository - or a part of it - to the branches or tags repositories, - Restoring a removed file or directory element to the HEAD revision. It is difficult for me to imagine a part (file or whole directory tree) copied to another place of the same software. This would be some kind of hardlinks (against SCM principles !). I don't know what I'm missing here. How is it better than explicit commit/update/switch operations? What happens if you are disconnected while making a change? What if you want your working copy to contain conflicts for a while before you can decide how best to resolve them? What is nice is : you don't load and you don't update, you just see exactly what is in the repository. Of course, you need to be connected - with a (very) good connection to the servers. If connection is lost, CC is reliable enough to avoid repository corruption. If you want to work on your side, you have to create a branch - nothing very new. How well does it deal with many concurrent changes with after-the-fact conflict resolution? Nothing very new again, users can always continue their work, but they have to merge at checkin. I think that CC and SVN are very close on this. Just that CC manages individual checkout with reservation, and this can block the work of the team. CC Admin have often to help in order to solve checkouts. I think SVN is better on this point. From: Andreas Krey As I understand it, when you commit your stuff it also becomes immediately visible in all other views that look at the same branch. That is a bit disturbing. Not really, this is like The 'dirty-trunk' style described by Les. People write on one same branch, this works for small team (5 max). Work is assigned to the developpers, and they should not work on the same files - most of the time. They have to communicate together if there is a change on some common file. If it is a bigger team, they can use continuous integration to manage the situation. Other than that, the dynamic view is an interesting tool to make a workspace visible on multiple machines; normally you'd either use NFS for that, or in 'commits are cheap and not carved in stone' VCS systems, you just commit and move that commit over to the target. Yes, that is right. There is one thing that potentially can cause a *lot* of pain: In Clearcase the views are always visible at the same path, no matter which branch/config spec result you're looking on. The software stored in there can accumulate a lot of reliance on these absolute paths over time, and they are hard to find during the migration. I dont understand ? From: Andrew Reedick Because in SVN, you're normally working in a workspace and not directly in the repository. 'svn log' is your 'ct find' in most cases. Plus, in SVN you're working in a workspace most of the time and the normal command line tools (e.g. find, dir /s) work just fine, so there's not much need to re-create the wheel with SVN equivalent commands. You need 'ct find' because all the history is tracked in each individual element, whereas in SVN, history is contained in each (global) revision. In other words, you're probably trying to apply CC paradigms to SVN. Ok, I will look more carefully to svn+log. SVN does that. But instead of applying labels to each element, svn simply makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0). In CC terms, it's conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a checkout/checkin on each element to create the REL1.0 branch. And then locking the REL1.0 branch so folks don't check into it. (But SVN's branching/tagging is very efficient and fast.) How do you lock your SVN tags, please ? You can get the link back to the branch point via 'svn log --stop-on-copy -v -r 1:HEAD -l 1'. (But there is an edge case which breaks that, requiring iterative use of 'svn log --stop-on-copy'. *grumble*) Nice ! Back in my day, CC snapshot views were terrible/horrible/nearly_unusable. SVN workspaces are simply great. I doubt your users will complain once they start using them. IME, the only downside to SVN workspaces/snapshots is that developers will whine about having to checkout a full directory tree no matter how small the tree. 'svn switch' helps reduce the need to checkout full workspaces, but it still doesn't reduce the whining though. :( Compared to WC, CC snaphot views are still less
Re: History in subversion
On Jun 16, 2013, at 15:55, Olivier Antoine wrote: When you commit, commit can fail, and you might have to merge before committing. If you commit, and the commit fails because one or more of the files you changed was also changed in the repository, then you have to svn update the working copy to receive the changes from the repository. You do *not* have to, and probably should not, svn merge anything at this point. You merge, you did some regression tests on the merged software, and then you finally commit. But it just mean that the software that you store in the repository is not strictly the software that you developped, and this software is simply lost. This is just against the SCM principles. If you're concerned about this, then svn cp your trunk to a new feature branch before beginning your work. Or even after you've finished your work, if such a situation arises. Let's say you check out a working copy of trunk. You make changes. You test them. You commit. The commit succeeds. Good; you're done. On the other hand, let's say you've made changes and tested them and try to commit and it fails because a file is out of date. You wish you had made a feature branch for these changes. No problem; you can still do it now. Use svn info on the working copy to find out what revision of trunk you had checked out. Let's say it was 1234. Make a feature branch in the repository from that revision of trunk (svn cp $REPO/trunk@1234 $REPO/branches/my-feature-branch). Switch the working copy to that branch (svn sw $REPO/branches/my-feature-branch). Commit the changes; it'll succeed. Now you have the state of the software you developed recorded in the repository in the feature branch. Now you can continue with the task of reintegrating the feature branch into trunk using svn merge.
Re: History in subversion
On Sun, Jun 16, 2013 at 3:55 PM, Olivier Antoine oliviera201...@gmail.com wrote: Taking the history in a copy is what makes svn work and it makes any copied directory functionally usable as a branch or tag. But after that it depends on how you actually use it... As consequence, SVN allows to create branches and tags on a part of the software of the repository, starting at a subdirectory and the copy command can then control/limit the scope of the branch/tag.This can be useful. The common scenario is to have multiple 'projects' under the same repository root, each with their own trunk/branches/tags tree. Now, I only see two uses of the command svn+copy - and two only : - Copy the software of the repository - or a part of it - to the branches or tags repositories, - Restoring a removed file or directory element to the HEAD revision. It is difficult for me to imagine a part (file or whole directory tree) copied to another place of the same software. This would be some kind of hardlinks (against SCM principles !). Once you have copied it, it goes its own way but retains previous history - there is nothing wrong with that. Consider a library that evolves as a component of some other project, but you subsequently realize it can be used in several programs that will be maintained separately. It might make sense to copy it up to its own top-level project where it can more sensibly have its own release schedule with its own branches and tags to easily support multiple versions concurrently being used by different things. I don't know what I'm missing here. How is it better than explicit commit/update/switch operations? What happens if you are disconnected while making a change? What if you want your working copy to contain conflicts for a while before you can decide how best to resolve them? What is nice is : you don't load and you don't update, you just see exactly what is in the repository. But - I don't like surprises... And I might have temporary local changes in my copy, or have intentionally set up a working copy with mixed revisions. So I guess you'd have to branch in the repository to match what svn does with working copies. How do you lock your SVN tags, please ? You can use hook scripts for that. We sometimes check out source from tags and commit the resulting binaries back - not exactly 'clean' but pragmatically useful - and possible with an appropriate script that allows this exception. Now, let me show you something in SVN that is disturbing for me (and other tool, like RTC, do the same). When you commit, commit can fail, and you might have to merge before committing. If you have concurrent work going on, it is usually best to update before and after your commit. And you'll resolve conflicts in the updates. You merge, you did some regression tests on the merged software, and then you finally commit. But it just mean that the software that you store in the repository is not strictly the software that you developped, and this software is simply lost. This is just against the SCM principles. If you want to store all copies of concurrent work instead of just the the way you resolved your updates, you need to be working on separate branches with later resolution. That's the 'feature branch' style and there are sometimes reasons to use it, even though there is some extra overhead. But regardless of the process, you eventually have to resolve conflicting changes. -- Les Mikesell lesmikes...@gmail.com
Re: History in subversion
On Thu, 13 Jun 2013 16:23:39 +, Les Mikesell wrote: ... Revision numbers can be renumbered one day in the repository, so they cannot be used in the SCM process, am I wrong ? No, revisions can never be renumbered in an existing repository. It is possible to dump the repository and load the history into a different one and change the revision numbers in the process, but that is a drastic administrative decision that will invalidate all checked-out workspaces. Uh, it would also invalidate any pegged revision used in externals, right? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: History in subversion
On Thu, 13 Jun 2013 21:57:17 +, Olivier Antoine wrote: ... I think that dynamic view is still a nice concept. Dynamic views is something that users like much, and they desespair when they have to migrate to snapshot views. You create your view, you have an (almost) real-time connection to the repository, your view is available immediatly on all the machines. As I understand it, when you commit your stuff it also becomes immediately visible in all other views that look at the same branch. That is a bit disturbing. Other than that, the dynamic view is an interesting tool to make a workspace visible on multiple machines; normally you'd either use NFS for that, or in 'commits are cheap and not carved in stone' VCS systems, you just commit and move that commit over to the target. But I never saw another tool with these principles : real-time access to repository, build based on version (not on time), winkin, We're at the point where simply compiling the sources on a local disk is faster than winking in the objects in in clearcase. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Thursday, June 13, 2013 3:57 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks All again for your help, If you're just trying to find a file in the current version of the repo, then svn ls -R svn://... You can use '-r' and peg revisions to search older revisions of the repo tree. Yes, I started a short perl script for this, but this is strange that nobody asked for a svn+find command (IMO). Because in SVN, you're normally working in a workspace and not directly in the repository. 'svn log' is your 'ct find' in most cases. Plus, in SVN you're working in a workspace most of the time and the normal command line tools (e.g. find, dir /s) work just fine, so there's not much need to re-create the wheel with SVN equivalent commands. You need 'ct find' because all the history is tracked in each individual element, whereas in SVN, history is contained in each (global) revision. In other words, you're probably trying to apply CC paradigms to SVN. Tree conflicts seem to be very mysterious. Why is there a such issue in SVN and not CC - what to think about this, please ? Directory merging wasn't in the initial design architecture of SVN... It's been added in bits since 1.4(?) and hasn't really gotten good until 1.6/1.7. And of course : Is it possible to do refactoring on any branch, and to merge to any branch without trouble ? Mostly. Again you have to deal with the limitations of 'merge --reintegrate' in 1.7.x (which goes away in 1.8.) If you are merging unrelated code (i.e. no common ancestor) then you're asking if SVN can merge Evil Twins. I think the answer is mostly yes, but I could be wrong because it's rare that I encounter that situation. Ideally, your branches have a common ancestry in order to make merge conflict resolution easier. You can ignore ancestry to merge unrelated trees, but if you find yourself merging often between unrelated (i.e. no common ancestor) branches, then I would hazard to say that there's something wrong with your branching process and/or baseline management (i.e. barring an exceptional use case, you might be using SVN incorrectly or working against SVN's branching paradigm?) Like I said above, I wish to continue : - to create tags on branch (and to keep the link of the tag with the branch) - and to create a branch from a tag (and to keep the information that the branch starts from this tag). These are raisonnable SCM principles, don't you think ? SVN does that. But instead of applying labels to each element, svn simply makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0). In CC terms, it's conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a checkout/checkin on each element to create the REL1.0 branch. And then locking the REL1.0 branch so folks don't check into it. (But SVN's branching/tagging is very efficient and fast.) You can get the link back to the branch point via 'svn log --stop-on-copy -v -r 1:HEAD -l 1'. (But there is an edge case which breaks that, requiring iterative use of 'svn log --stop-on-copy'. *grumble*) I think that dynamic view is still a nice concept. Dynamic views is something that users like much, and they desespair when they have to migrate to snapshot views. You create your view, you have an (almost) real-time connection to the repository, your view is available immediatly on all the machines. The working copy needs to be loaded, recreated and reloaded on each machine. Back in my day, CC snapshot views were terrible/horrible/nearly_unusable. SVN workspaces are simply great. I doubt your users will complain once they start using them. IME, the only downside to SVN workspaces/snapshots is that developers will whine about having to checkout a full directory tree no matter how small the tree. 'svn switch' helps reduce the need to checkout full workspaces, but it still doesn't reduce the whining though. :( But I never saw another tool with these principles : real-time access to repository, build based on version (not on time), winkin, configuration audit, SCM process level (stream, baseline, component), multisite. Yes, but in practice, you don't really need real time access to a repository. In SVN, you do your work, then when you're ready, you run 'svn update' to pull in other people's changes. Meaning, you decide when to take changes instead of having random changes spontaneously appear in your view. It helps to remember that SVN was designed to support open source projects with developers spread across the world. It's why hooks are server side only (instead of client side hooks,) why workspaces are snapshots instead of dynamic views, why svn URLs are URLs, etc.
Re: History in subversion
Thanks All again for your help, From: Les Mikesell I did not understand everything with branches and tags, I have to read again the manual, but I have the feeling that branches and tags are not linked, this is strange to me. Linked to what? Think of them as 'cheap copies' of whatever they are copied from. And remember that subversion doesn't really know or care that they are branches or tags - that's your convention and if you follow it everything works fine. A good SCM principe is : - to create tag on branch - to create branch from tag I seems to work well with svn, svn log -v gives : Changed paths: A /tags/RST_DEV_1.0.0 (from /branches/rst_dev_1.0.0:64) Changed paths: A /branches/rst_cor_1.1.0 (from /tags/RST_DEV_1.0.0:65) that's nice. Have you read The book: http://svnbook.red-bean.com/ ? If you have, try again to get a better understanding of what subversion operations are inherent in the server/repository and what are just conventions or client-side concepts. The idea of merge-tracking does make this part a little fuzzy. I'm reading this (I think this is what you're talking about) : Version Control with Subversion For Subversion 1.7 (Compiled from r4470) From Andrew Reedick : This should help you to find files and what rev they're in. '^/' is the path or svn url to check. Foo.java is the file or regex you're looking for. svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if /foo.java/;' It works, thanks. If you're just trying to find a file in the current version of the repo, then svn ls -R svn://... You can use '-r' and peg revisions to search older revisions of the repo tree. Yes, I started a short perl script for this, but this is strange that nobody asked for a svn+find command (IMO). There's no such thing as a uuid or oid in SVN (or at least one that is user visible.) Instead, you can use svn_url + revision number or svn_url + 'Last Changed Rev' (which can be found via 'svn info') in order to uniquely identify a particular revision of something. 'Last Changed Rev' is preferable. Ok, The two most complex commands for SVN seems to be svn+copy and svn+merge, Thanks for your explaination on svn+copy, it helps, because I was surprised to see how svn+copy duplicates history. The kinds of people who merge random dirs together tend to be Darwin candidates, so it's a self-correcting activity. I guess I'm part of the candidates :-)) The only real merging landmines are 'svn merge --reintegrate' and tree conflicts. The former you can read up on (and which is going away in 1.8), the latter is poorly documented and more annoying/tedious than painful. Tree conflicts seem to be very mysterious. Why is there a such issue in SVN and not CC - what to think about this, please ? And of course : Is it possible to do refactoring on any branch, and to merge to any branch without trouble ? A tag is a branch is a directory. Tags and branches aren't real objects in SVN. They're just directories that are treated as special by their human masters. Since tags are branches, it's common to use a pre-commit hook or auth file to limit write access to a tag. In practice, there's not a lot of difference between SVN checking in a change to a tag and CC moving a label to a new version on a file/dir. Like I said above, I wish to continue : - to create tags on branch (and to keep the link of the tag with the branch) - and to create a branch from a tag (and to keep the information that the branch starts from this tag). These are raisonnable SCM principles, don't you think ? Revision numbers can be renumbered one day in the repository, so they cannot be used in the SCM process, am I wrong ? IMHO, SVN's workspaces are light years ahead of CC's dynamic views and static workspaces in terms of ease of use. Tagging in SVN is effectively instantaneous. All of the cool stuff in CC that made for geeky CC admins isn't needed, meaning I haven't missed dynamic views, config specs, lazy branching, individual version trees, being able to cd into an element's version tree, having to merge dirs iteratively before merging files, etc., after converting to SVN. CC's slow history, slow labeling, latency issues, etc., aren't present in SVN. (However, to be fair, early versions of SVN were horrific (no merge tracking, no dir merges, etc.) but svn 1.7 is good enough outside of the --reintegrate issue.) In other words, SVN's working paradigm is much simpler than CC's, and most of CC's super-special, gee-whiz features just aren't needed. In my experience/opinion, Subversion ClearCase. I think that dynamic view is still a nice concept. Dynamic views is something that users like much, and they desespair when they have to migrate to snapshot views. You create your view, you have an (almost) real-time connection to the repository, your view is available immediatly on all the machines. The working copy needs to be loaded, recreated and reloaded on each
Re: History in subversion
On Thu, Jun 13, 2013 at 2:57 PM, Olivier Antoine oliviera201...@gmail.com wrote: A good SCM principe is : - to create tag on branch - to create branch from tag I think most people settle on one of two basic 'styles'. The 'dirty-trunk' style makes the most sense to me where most development happens on the trunk with development branches only happening for disruptive or experimental changes. As the trunk approaches a new release point, you make branches for testing and final development and tags for any revisions you want to be able to recreate. Before merge-tracking worked well this minimized the amount of merging since everything progresses in the same direction. It also encourages developers to take advantage of each others changes and sort out conflicts early - and it lets you maintain multiple releases concurrently on their own branches. The other approach keeps the trunk stable and always usable by using 'feature branches' for all new work, merging back to trunk after completion and testing as a form of release management. Of course you can mix/match styles as appropriate for your workflow. The two most complex commands for SVN seems to be svn+copy and svn+merge, Thanks for your explaination on svn+copy, it helps, because I was surprised to see how svn+copy duplicates history. That's pretty much the point of it... Like I said above, I wish to continue : - to create tags on branch (and to keep the link of the tag with the branch) - and to create a branch from a tag (and to keep the information that the branch starts from this tag). Just remember that svn tracks the 'copied from' history so it can do sensible things when merging, updating, diffing, etc., objects with common ancestry. It doesn't track the 'copy to'. These are raisonnable SCM principles, don't you think ? Taking the history in a copy is what makes svn work and it makes any copied directory functionally usable as a branch or tag. But after that it depends on how you actually use it... Revision numbers can be renumbered one day in the repository, so they cannot be used in the SCM process, am I wrong ? No, revisions can never be renumbered in an existing repository. It is possible to dump the repository and load the history into a different one and change the revision numbers in the process, but that is a drastic administrative decision that will invalidate all checked-out workspaces. But, this eventual possibility is one of the reasons that you want your own human-friendly branch/tag names for the revisions you will always want to be able to find. I think that dynamic view is still a nice concept. Dynamic views is something that users like much, and they desespair when they have to migrate to snapshot views. You create your view, you have an (almost) real-time connection to the repository, your view is available immediatly on all the machines. The working copy needs to be loaded, recreated and reloaded on each machine. I don't know what I'm missing here. How is it better than explicit commit/update/switch operations? What happens if you are disconnected while making a change? What if you want your working copy to contain conflicts for a while before you can decide how best to resolve them? But I never saw another tool with these principles : real-time access to repository, build based on version (not on time), winkin, configuration audit, SCM process level (stream, baseline, component), multisite. How well does it deal with many concurrent changes with after-the-fact conflict resolution? -- Les Mikesell lesmikes...@gmail.com
Re: History in subversion
Thanks All for your help and advices, From: Les Mikesell : svn logs will show file/directory additions/deletions in the parent directory, so you should be able to track the history of things that way if you wanted, but what is it that you specifically need to do? Most people would just check out some directory level and diff it against some other revision or a branch or tag. Ok, svn log -v will help, But : With CC, I can easily search for any file element in a repository, and directly get its path, With SVN, I have to check all revisions, then I can know where this element is located in the repository (maybe several locations), I can find in which revision it was removed. This is double manual search. When users ask for help, I have to go in their repository that I don't know at all, users often give less than half the information I need to locate the file where they need help. With CC, I can quickly analyze a repository, and get easily the missing information. With SVN, I feel like blind, because I cannot do the same analysis on the repository. I cannot do a global search, I have to check the revisions individually. About peg revision : Peg revision means that I can access any file and directory version without checkout, this is already a nice help. But : is there also an individual identifier for directory and file (uuid, oid, ..) ? From: Andrew Reedick I used to use ClearCase in a past life (3.0 - 6.0). I haven't missed the ability to diff dirs. You might be stuck on doing things the CC way instead of learning the Subversion paradigms. It's going to be frustrating for a little while (it was for me.) What are you trying to do that requires diff'ing the contents of directories? Could you help more on diff dirs, please : - What is the best way with SVN to compare a same directory on two different branches ? I am very confused by many things with SVN, one of them is : - I can merge from any directory to any directory anywhere, and I just get a terrible Tree conflict. With CC, the merge is inside the version tree of the file or directory element. This kind of mistake is not possible. I don't understand why it is done like this with SVN. I did not understand everything with branches and tags, I have to read again the manual, but I have the feeling that branches and tags are not linked, this is strange to me. From: Andrew Reedick To re-emphasize, I'm very serious about the need to stop trying to apply CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of doing things didn't provide significant advantages in (or over) SVN. I understand, and I don't try to use SVN in the CC way. SVN and CC are tools, the goal for me is the software configuration management of the projects, and also to be able to help the users of the tools in the best way. On the other hand, I'd like to understand and compare the capabilities of both tools by myself, because what I read in the past was not detailed enough in my opinion. Thanks 2013/6/11 Olivier Antoine oliviera201...@gmail.com Hi, I'm trying to work with SVN, but coming from ClearCase, I'm lost. It seems that it is not possible to consult the history of the repository like in CC, I can get the history of a file element with svn+annotate, I can use svn+diff on files, But for directories : no annotate, no diff - nothing ? Do I have to check all the repository revision set in order to follow the changes on a directory element ? Regards Olivier
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Wednesday, June 12, 2013 3:42 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks All for your help and advices, But : With CC, I can easily search for any file element in a repository, and directly get its path, With SVN, I have to check all revisions, then I can know where this element is located in the repository (maybe several locations), I can find in which revision it was removed. This is double manual search. You cannot directly diff two revisions of a directory, where diff is defined as diff'ing the list of file/dir objects in the directory. Instead, SVN will diff the files under the directory tree. From a CC point of view, svn file objects are first class objects with version a version tree, history, etc., whereas SVN directory objects are not. (SVN dirs are second class-ish.) This should help you to find files and what rev they're in. '^/' is the path or svn url to check. Foo.java is the file or regex you're looking for. svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if /foo.java/;' When users ask for help, I have to go in their repository that I don't know at all, users often give less than half the information I need to locate the file where they need help. With CC, I can quickly analyze a repository, and get easily the missing information. With SVN, I feel like blind, because I cannot do the same analysis on the repository. I cannot do a global search, I have to check the revisions individually. If you're just trying to find a file in the current version of the repo, then svn ls -R svn://... You can use '-r' and peg revisions to search older revisions of the repo tree. About peg revision : Peg revision means that I can access any file and directory version without checkout, this is already a nice help. But : is there also an individual identifier for directory and file (uuid, oid, ..) ? There's no such thing as a uuid or oid in SVN (or at least one that is user visible.) Instead, you can use svn_url + revision number or svn_url + 'Last Changed Rev' (which can be found via 'svn info') in order to uniquely identify a particular revision of something. 'Last Changed Rev' is preferable. However, since SVN doesn't have true renames, 'svn copy' will normally create a new object with a new revision (aka last changed rev) number. A new revision number won't be created if you copy the parent dir the file is in. In CC parlance, instead of /repo/branches/1.0/foo.java and /repo/trunk/foo.java just being hard links to revision object #1452134521, in svn you wind up with either a new revision number: 1. svn copy /repo/trunk/foo.java /repo/branches/1.0/foo.java 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 123 Or if you copy the parent dir, foo.java's rev number remains unchanged: 1. svn copy /repo/trunk /repo/branches/1.0 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 100 So technically yes, SVN has the Evil Twin problem, however, it doesn't really cause problems with file merges per se, so Evil Twins aren't really a problem. Directory tree merges on the other hand, can be murder, but tree conflicts have been greatly improved in 1.7. Could you help more on diff dirs, please : - What is the best way with SVN to compare a same directory on two different branches ? 'svn diff', or checkout/export both branches (directories) and run your favorite diff tool on them. If you want to diff the contents of the dirs (i.e. the hard links,) then you can try 'svn ls -v' and diff the output (look at the rev numbers.) Generally speaking, in SVN, you don't diff directories, you diff the files in the baselines (aka branches.) However, since SVN revisions are changesets (a collection of related changes,) you can also use 'svn mergeinfo' to diff two baselines/branches/directories (i.e. find what changes have not been applied from branchA to branchB.) Or you can just run the merge command to see what would get merged and then 'svn revert -R' to get back to a clean workspace (instead of checking in.) You can even do a a 'svn merge --ignore-ancestry' to merge unrelated trees (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata) Long story short, if you are managing changesets between branches, then svn is quite adequate. If you're diffing code trees, then something has gone wrong with your merges and/or change management process. =) I am very confused by many things with SVN, one of them is : - I can merge from any directory to any directory anywhere, and I just get a terrible Tree conflict. With CC, the merge is inside the version tree of the file or directory element
Re: History in subversion
On Wed, Jun 12, 2013 at 10:45 PM, Les Mikesell lesmikes...@gmail.com wrote: On Wed, Jun 12, 2013 at 2:41 PM, Olivier Antoine oliviera201...@gmail.com wrote: ... Could you help more on diff dirs, please : - What is the best way with SVN to compare a same directory on two different branches ? Just check one out and diff the workspace against a different revision or branch path or both. Or 'svn diff --old=^/branches/branch1 --new=^/branches/branch2' (The ^/ syntax is shorthand for the repository root, when your current working directory is inside a working copy (so svn can discover what repository you're referring to). On Windows you have to escape the ^, so it becomes ^^/). In 1.8 you'll no longer need the --old / --new options for comparing two arbitrary URLs, you can just type: svn diff ^/branches/branch1 ^/branches/branch2 -- Johan
Re: History in subversion
On Tue, Jun 11, 2013 at 3:15 PM, Olivier Antoine oliviera201...@gmail.com wrote: I'm trying to work with SVN, but coming from ClearCase, I'm lost. It seems that it is not possible to consult the history of the repository like in CC, I can get the history of a file element with svn+annotate, I can use svn+diff on files, But for directories : no annotate, no diff - nothing ? Do I have to check all the repository revision set in order to follow the changes on a directory element ? You want svn log. The book has a good explanation: http://svnbook.red-bean.com/en/1.7/svn.tour.history.html -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: History in subversion
I don't think that svn log describes the history of the directory element, Actually I don't see any command that could give the revisions where the directory changed (tree changes), without giving the changes on the files it contents. No svn+annotate on directories. And I don't see any way to apply svn+diff on the directory element only I tried : svn diff --depth empty = but got only properties information. 2013/6/11 Olivier Antoine oliviera201...@gmail.com Hi, I'm trying to work with SVN, but coming from ClearCase, I'm lost. It seems that it is not possible to consult the history of the repository like in CC, I can get the history of a file element with svn+annotate, I can use svn+diff on files, But for directories : no annotate, no diff - nothing ? Do I have to check all the repository revision set in order to follow the changes on a directory element ? Regards Olivier
Re: History in subversion
On Tue, Jun 11, 2013 at 4:02 PM, Olivier Antoine oliviera201...@gmail.com wrote: I don't think that svn log describes the history of the directory element, OK, did not pick up that you were only interested in that information. You are right that SVN will always show the information for directory plus children. The only changes to a directory that SVN tracks are prop changes, so in general the history of a folder is uninteresting. If you wanted the changes to just the directory you would need to use the --verbose option on log which will print the changed paths. You would then have to parse out the interesting revisions by finding the ones where the folder path is included. Actually I don't see any command that could give the revisions where the directory changed (tree changes), without giving the changes on the files it contents. No svn+annotate on directories. And I don't see any way to apply svn+diff on the directory element only I tried : svn diff --depth empty = but got only properties information. That is all you would get for a directory. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: History in subversion
Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file I tried, it doesn't work. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? 2013/6/11 Olivier Antoine oliviera201...@gmail.com Hi, I'm trying to work with SVN, but coming from ClearCase, I'm lost. It seems that it is not possible to consult the history of the repository like in CC, I can get the history of a file element with svn+annotate, I can use svn+diff on files, But for directories : no annotate, no diff - nothing ? Do I have to check all the repository revision set in order to follow the changes on a directory element ? Regards Olivier
Re: History in subversion
On Tue, Jun 11, 2013 at 4:45 PM, Olivier Antoine oliviera201...@gmail.com wrote: Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? It is open-source, so nothing is stopping someone from implementing this if they find it important. I think most of us do not see a need for it so it has not risen to the level of being someone's itch to scratch. I am sure someone has scripted this but whether they shared it and you can find it are questions I cannot answer. It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file I tried, it doesn't work. Have you tried this? http://subversion.apache.org/docs/release-notes/1.6.html#historical-uris Note that would just be for using something like curl or wget. A svn client has always been capable of doing this. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? Restoring something that was removed is easy. However, finding the element and when it was deleted is unfortunately not easy. As with the previous example, you would want to run svn log with the --verbose option and parse the output to find the revision when the item was removed. Looking at the history of a parent folder for the item would show when it was deleted, but you would have to search the output or script it. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: History in subversion
On Tue, Jun 11, 2013 at 3:45 PM, Olivier Antoine oliviera201...@gmail.com wrote: Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? svn logs will show file/directory additions/deletions in the parent directory, so you should be able to track the history of things that way if you wanted, but what is it that you specifically need to do? Most people would just check out some directory level and diff it against some other revision or a branch or tag. It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file I tried, it doesn't work. The revnumber is global to the whole repository, so path/file@revnumber would mean the same thing. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). You need a starting point and you can log backwards. If you are just browsing, tools like tortoise or web interfaces like viewvc or websvn might be easier. Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? If you know the parent directory the log will show the deletion and the revision number where it occurred. But if there were many additions/deletions of files of the same name or at different places in the tree it can be hard to find the one you want. -- Les Mikesell lesmikes...@gmail.com
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Tuesday, June 11, 2013 13:45 To: users@subversion.apache.org Subject: Re: History in subversion Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file I tried, it doesn't work. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). Unlike ClearCase, Subversion does not have elements each with their own history. Rather, the whole repository is versioned with each commit. So, there is no benefit to this syntax: directory@revnumber/file Instead, use: directory/file@revnumber The Revision identifies a snapshot of the whole repository, not just some snapshot of a directory. -Steve Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? 2013/6/11 Olivier Antoine oliviera201...@gmail.com Hi, I'm trying to work with SVN, but coming from ClearCase, I'm lost. It seems that it is not possible to consult the history of the repository like in CC, I can get the history of a file element with svn+annotate, I can use svn+diff on files, But for directories : no annotate, no diff - nothing ? Do I have to check all the repository revision set in order to follow the changes on a directory element ? Regards Olivier
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Tuesday, June 11, 2013 4:45 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? I used to use ClearCase in a past life (3.0 - 6.0). I haven't missed the ability to diff dirs. You might be stuck on doing things the CC way instead of learning the Subversion paradigms. It's going to be frustrating for a little while (it was for me.) What are you trying to do that requires diff'ing the contents of directories? It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file You want to read up on peg revisions: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html You don't need to specify the rev for each path in the component, e.g. /view/foo/path@1/foo@2/bar@3/j.java@5. In SVN, the rev number is global, so you just /path/foo/bar/j.java@5. I tried, it doesn't work. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). Use svn export (or for individual files, svn cat) Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? You'll need to use a peg revision, e.g. svn copy svn:///path/foo.java@1234 . To find the revision that the file was in can be tricky if you have deleted a parent dir. In the average case, you can run svn log -v -q ^/path/to/branch log.txt. Then search the text file for your missing file to get the revision. You can also use svn log -v -q | egrep '^r|\/foo.java'. Worse case (you deleted a parent dir), you'll need to run the 'svn log' against the root of the repository (svn log -v -q ^/). To re-emphasize, I'm very serious about the need to stop trying to apply CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of doing things didn't provide significant advantages in (or over) SVN.
Re: History in subversion
On Jun 11, 2013, at 15:45, Olivier Antoine wrote: But this is very poor compared to ClearCase. Nobody tried to script that ? Most of us have never seen or used ClearCase. It might help if you provided a specific example of a command that you might run with ClearCase, and the output you would expect to receive from it. Then perhaps we can show you the Subversion way to get that information.
