Migrating ClearCase data to Subversion
Hi, I could not find a tool or an automated way to migrate ClearCase vobs to SVN repositories. I guess there is not any perfect tool to do this. I don't think I can use timestamp to build revisions, like for migration cvs to svn. On the other hand, the real need is to migrate main to trunk, to migrate the other branches, probably just for the interesting file/directory versions - the labelelled ones. I have to migrate the ClearCase labels to SVN tags. I guess it is not possible to migrate the merge history. Could you help, please ? Olivier
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
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
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
History in subversion
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
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
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
Conflicts with merge
Hi, Trying to understand how merge works for svn, I did a merge from a branch to trunk, and I get this: Skipped 'test1.c' -- Node remains in conflict Uhomo_script_sql.sql Skipped 'ARBO1' -- Node remains in conflict Uhomo_script_ddl.sql Skipped 't.dat' -- Node remains in conflict Skipped 'TEST1' -- Node remains in conflict G . Updated to revision 12. Summary of conflicts: Skipped paths: 4 I dont see how to solve these conflicts, how to do please? Regards Olivier
Re: Graphical version tree
Ok, Thanks for your help, Regards Olivier 2013/4/5 Thorsten Schöning tschoen...@am-soft.de Guten Tag Olivier Antoine, am Freitag, 5. April 2013 um 06:56 schrieben Sie: In your opinion, what is the best one for Windows, please? Please always answer to the list. It really depends on how you are working and the tools you use. I like TortoiseSVN very much, but I'm working on a per file basis fairly often, e.g. with configuration files, most of our software is not installer based etc., and with Subclipse in Eclipse. But I don't use revision graphs very often. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Graphical version tree
Hi, In your opinion, what is the best one for Windows, please? Regards Olivier 2013/4/3 Thorsten Schöning tschoen...@am-soft.de Guten Tag Olivier Antoine, am Mittwoch, 3. April 2013 um 20:52 schrieben Sie: I'd like to know if there is a tool that could display a graphical representation of the version tree of a file? Search for subversion revision graph and pick the tool you like the most. There are really a lot of different tools for different needs. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Graphical version tree
Hi, I'm beginning with Subversion, I'd like to know if there is a tool that could display a graphical representation of the version tree of a file? Regards, Olivier
