[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

A question about merging and conflicts

From: Mike Migurski <mike_at_saturn5.com>
Date: 2003-04-19 01:10:25 CEST

Greetings everyone -

I am not a developer, but I've been assured that is the appropriate forum
to ask user questions.

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

In Subversion, I have been working with a test repository, attempting to
induce conflicts to see how they are handled. For example, I copy trunk to
branch/branch4 (revision 23) and proceed to make changes to each that are
intended to conflict with one another. (revision 28, after a few such
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 -
does this mean that I have to remember the revision number at which I
created the branch?

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. I've been
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. In CVS I can look at a list of a file's applied tags with
status -v, not so in subversion.

I'd love to find out why the removal of CVS' "branch space" is an
improvement - currently it's a major stumbling block for working with
branches, something I do extensively.

michal migurski- contact info and pgp key:
sf/ca http://mike.teczno.com/contact.html

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 19 01:11:06 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.