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 machine. Config Spec is a complex tool, it allows a lot, but is too complex for the users. I don't understand why they didn't simplify this. Merging directories before files is not necessary since a long time with CC. The svn+diff seems very powerful, it will be easier to get the changeset between two labels, even on different branches (difficult with CC). Labelling with CC is very slow, yes (even if they found a solution with UCM, that they never applied to base CC). Managing individual checkouts is often painful with CC. Atomic checkin is a nice idea. CC is twenty years old, and it didn't change much. It was well adapted to the network architecture of the companies at the beginning, but everything changed with the web. Developments on CC are slow, if existing. And they want to replace it with RTC (Rational Team Center). 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. Now I agree that CC is (very) expensive, and often very slow, that it didn't evolve, CC web is a failure, UCM dependencies were never solved, and so on. Thanks >
