On Fri, Apr 18, 2003 at 04:10:25PM -0700, Mike Migurski wrote:
>
> I am not a developer, but I've been assured that is the appropriate forum
> to ask user questions.
yep.
> I'm having difficulty making the transition between branches/merges in CVS
> and Subversion. I'm attempting to duplicate CVS' behavior, where the '-j'
> option to update tracks edits through to the branchpoint, and flags
> conflicts.
as you've presumably noticed, 'svn merge' requires *two* source URLs or
revisions, e.g.
svn merge -r23:HEAD file:///path/to/branch/branch4 .
will merge all the changes from rev 23 to the tip of the branch into
your local working directory.
> edits in both). Now, in the trunk, it seems that the only way to generate
> the conflict is to specify revision 23 after the -r switch to update -
you say 'only way to generate the conflict'... what other ways of
merging did you try? (i agree that it's the only way to generate the
conflict, but only because it's the only way to tell subversion to do
the merge that you are trying to do. and of course, i'm assuming you
mean what i think you mean -- it would be better if you spelled out the
actual command lines you used.)
> does this mean that I have to remember the revision number at which I
> created the branch?
i believe so.
eventually a smarter merge feature is planned, which will remember not
only your branch point but all intermediate merge points, and Do The
Right Thing (tm). That is a Post-1.0 feature, though.
i'm not sure if there's any reason we couldn't assume the branch point
if given only one source URL, though... somebody else will have to
comment on that.
> In CVS, I would create branch- and merge-point tags to ease the subsequent
> merging process, but here it seems that tags have no special meaning apart
> from branches or directories, and therefore aren't much help.
tags aren't much help, because in Subversion, you get a tag for free
with every commit -- the revision number.
(granted, tag names are easier to remember than revision numbers;
but that's their only advantage.)
incidentally, have you tried making a tag (i.e., extra copy) when you
branch, and then doing your merge like this?:
svn merge file:///path/to/tag file://path/to/branch
... i havent tried it myself, but i can't think of why it wouldn't work.
although personally, i'd probably just write down the branch revnum --
seems easier.
> able create a conflict when I've specified revision 23, but have yet to
> figure out a way to figure out this revision number based on logs or
> status info.
try 'svn log -qv file:///path/to/branch | less' ...
scroll down until the Changed paths stop being branch paths and start
being trunk paths. the last branch path you see should look something
like:
rev 4527: rassilon | 2003-01-23 07:55:20 -0800 (Thu, 23 Jan 2003)
Changed paths:
A /branches/issue-1003-dev (from /trunk:4526)
> In CVS I can look at a list of a file's applied tags with
> status -v, not so in subversion.
well, in Subversion you probably wouldn't query individual files for tags.
instead, you'll probably do something like:
svn ls file:///repo/myproj/tags
and see what tags exist.
Subversion does rely somewhat more heavily on user conventions than CVS.
IMO that makes it more flexible and general, at little-to-no cost to the
user.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 19 02:44:57 2003