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

Re: A question about merging and conflicts

From: Mike Migurski <mike_at_saturn5.com>
Date: 2003-04-19 03:36:39 CEST

Thank you Brain - I realize that I can't expect to interact with svn the
same way I do with cvs, but I do hope to eventually be able to make the
switch completely. Subversion does offer a lot of advantages over cvs,
though I need to accustom myself to a certain lack of transparency in the
repository.

>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.

Yes, I did notice this - it begs the question, how might one avoid having
to explicitly type the full repository path everytime? I realize this only
really comes up when branches are dealt with, but is there a shorthand for
specifying the current repository, or at least the file://path/to/rep./
part? My repository path is long, and the file:// part means that
autocomplete doesn't work. I can set environment variables, but they will
work for only one repository at a time.

>> 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.)

That, and there's fewer of them, allowing for quick-n-easy scans of the
output of cvs status - this is the chief way I use them. I usually have
some seminal file at the module root (Makefile, typically) which I can
count on to contain every tag applied throughout the module's history.

I realize this is an inelegant hack. :)

>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.

This was one of the other methods I tried - I haven't investigated it
completely, but the behavior i was initially getting seemed to suggest
that it could tell what the difference between tag/ and branch/ was, but
not that those differences had any relation to what was going on in trunk/
(the current directory at the time).

>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:

This is more informative, thank you.

By the way, I've made the following addition to my .cshrc file, which
has made interactions with SVN somewhat quicker:

complete svn \
    'p/1/(add cat checkout commit copy remove diff help info \
    list log merge move propdel propedit propget proplist \
    propset revert resolve status switch update)/' \
    'n/help/(add cat checkout commit copy remove diff info \
    list log merge move propdel propedit propget proplist \
    propset revert resolve status switch update)/' \
    'n/proplist/f/' \
    'n/proplist/d/' \
    'n/prop*/(svn:eol-style svn:mime-type)/' \
    'n/svn:eol-style/(native CRLF LF CR)/'

---------------------------------------------------------------------
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 03:37:23 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.