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
>
Received on 2013-06-13 21:57:48 CEST