You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dylan Cuthbert <dy...@q-games.com> on 2002/09/06 12:32:21 UTC
Question regarding merging branches
I have the following
repo/trunk/projects/Makefile
and
repo/branches/test-branch/projects/Makefile
which was svn cp'd at say version "5"
I then edit both of these files (checked out into different places of
course) and commit both changes with no problem. I make sure I edit the
same part of the file to cause a "clash".
I now want to merge repo/branches/test-branch/projects into the trunk. I
type this:
( I am in the checked out trunk/projects directory )
svn diff http://svnserver/svn/repo/branches/test-branch/projects . <= note
the "."
and I am shown this:
Index: Makefile
===================================================================
--- Makefile
+++ tmp.35072.00001 2002-09-06 21:28:15.000000000 +0900
@@ -1,4 +1,4 @@
-# a test commit
+#conflict central
#---------------------------------------------------------------------------
----
#
# Makefile for gnu-make
@@ -9,7 +9,6 @@
# (c) 2001,2002 Q-Games
#
#---------------------------------------------------------------------------
----
-# is it working!?
#
# set PROJECT to project name (target file derives from this)
# set PROJECTS_DIR to base directory of all projects
When I do an svn merge it doesn't modify the trunk's Makefile - why not?
What am I doing wrong? I'm new at this so maybe there's something I'm not
grasping.
I get this when I do a merge:
$ svn merge http://svnserver/svn/repo/branches/test-branch/projects . <=
note the "."
_ Makefile
Shouldn't I get a conflict to fix?
Regards
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> Well, no, I don't get the conflict messages, I just get the U or the G
> letter when I issue the merge command and the conflicting area is left the
> same as the trunk version (because there are no local mods). I'd prefer to
> have a C, and the culprit lines highlighted "cvs-style", preventing me being
> able to commit until I resolve the problem. This behaviour isn't happening
> in the current version. It merges all the changes from the branch into the
> trunk that don't have conflicts, all conflicts are left as whatever the
> trunk version is.
If there is a conflict, you do get a 'C', and the conflicting areas
are highlighted CVS-style.
If this is not happening for you, it's a bug, and it would be great if
you could give a precise reproduction recipe (see the guidelines in
the HACKING file).
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Bill Tutt" <ra...@lyra.org> wrote in message
news:58C671173DB6174A93E9ED88DCB0883D05A1C2D4@red-msg-07.redmond.corp.micros
oft.com...
>
>
> > From: Dylan Cuthbert [mailto:dylan@q-games.com]
> >
> > Or maybe there's some subtlety that I'm missing again. :-)
> >
>
> Well, you do know what's been merged, and what generated conflicts.
Well, no, I don't get the conflict messages, I just get the U or the G
letter when I issue the merge command and the conflicting area is left the
same as the trunk version (because there are no local mods). I'd prefer to
have a C, and the culprit lines highlighted "cvs-style", preventing me being
able to commit until I resolve the problem. This behaviour isn't happening
in the current version. It merges all the changes from the branch into the
trunk that don't have conflicts, all conflicts are left as whatever the
trunk version is.
Regards
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> I understand that no data gets lost, but when merging a branch with, say,
> 100 files or more, all of which have committed changes, some conflicting,
> some not, I end up with no idea what's been merged and what hasn't. This
> seems very error-prone.
>
> Or maybe there's some subtlety that I'm missing again. :-)
No, there's no subtlety, this is just the way Subversion (and CVS)
resolves conflicts. It tells the user there is a conflict, gives them
all the information they need to resolve the conflict (including the
unmerged versions of both the working file and the repository file),
and then assumes that the user will take care of the situation.
You may initially have "no idea what's been merged and what hasn't",
but judicious use of the `diff' program will change that...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> What's the current *realistic* ETA for v1?
When it's ready :-).
Seriously: we only schedule one or two milestones ahead, that's worked
out best.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Ben Collins-Sussman" <su...@collab.net> wrote in message
news:86ofb6pogn.fsf@kepler.ch.collab.net...
>
> Yes, we fully plan to use metadata properties to have svn track
> exactly when and where things got branched, and how things got
> remerged. It's a big post-1.0 thing.
>
> For now, users have to manually keep track of this stuff. :-(
Cool.. because ease-of-branching seems to be one of the biggest "plusses" of
switching to using subversion over continuing using cvs. I suppose I can
knock up a script in the meantime to help "automate" the process for the
users on my network. Has anyone got a pre-cooked script to help this out?
What's the current *realistic* ETA for v1?
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
>
> The cause of the confusion were a no. of user-interface issues, one was the
> fact you have to specify the branch and head revisions manually, I think
> this should be automatic and per file (in case individual files have been
> copied/branched), it should be possible to search back for a common branch
> point, or maybe it should be a standard meta-data for all files/directories
> so you can enter something like "svn branched <file/dir>" and that lets svn
> know the branch is on that revision. Of course, I'm new to this list, so
> you've probably discussed this problem and already found a solution and its
> just not implemented yet?
Yes, we fully plan to use metadata properties to have svn track
exactly when and where things got branched, and how things got
remerged. It's a big post-1.0 thing.
For now, users have to manually keep track of this stuff. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Ben Collins-Sussman" <su...@collab.net> wrote in message
news:86sn0ippk9.fsf@kepler.ch.collab.net...
> "Dylan Cuthbert" <dy...@q-games.com> writes:
>
> > It seems that this kind of patching will generate bugs because it is
> > "piecemeal". ie. parts of the file get updated because there's no clash,
and
> > other parts don't because there is. However, the parts that do get
updated
> > might rely on the changes in the clashing parts. (as they are all in the
> > same file)
>
> This is not a new model; CVS has been doing this for 15 years.
Yep, I know that, sorry, the original mail I was responding to described it
a little incorrectly and I took it literally, but once I specify the exact
branch and head revisions when I use the merge command from the parent
directory I do get the conflict, so all's fine and dandy. I have no problem
with that behaviour.
The cause of the confusion were a no. of user-interface issues, one was the
fact you have to specify the branch and head revisions manually, I think
this should be automatic and per file (in case individual files have been
copied/branched), it should be possible to search back for a common branch
point, or maybe it should be a standard meta-data for all files/directories
so you can enter something like "svn branched <file/dir>" and that lets svn
know the branch is on that revision. Of course, I'm new to this list, so
you've probably discussed this problem and already found a solution and its
just not implemented yet?
Anyway, when I tried to use the merge command without the "-r" I simply got
a partial update and conflicts were ignored, and it was confusing.
The other problem was the "." directory specification not working when
attempting a merge *with* the -r option. So I was stuck in a bit of a loop
until I found it works from the parent directory.
Regards
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> It seems that this kind of patching will generate bugs because it is
> "piecemeal". ie. parts of the file get updated because there's no clash, and
> other parts don't because there is. However, the parts that do get updated
> might rely on the changes in the clashing parts. (as they are all in the
> same file)
This is not a new model; CVS has been doing this for 15 years.
As Bill Tutt said -- CVS and Subversion can do contextual, line-based
merges. This purely syntactic, not semantic. There's no guarantee
you'll get semantically correct tode.
Similarly, even if a merge happens perfectly on a file, there's no
guarantee that the project as a whole will be semantically correct.
These are problems only solvable by human coordination.
If you don't want 'diff3' to run (which causes the contextual
merging), just set the 'svn:mime-type' property on the file to
anything other than 'text/*'. Whenever you update or merge, your
working file will be placed side-by-side with the new file; you can
then use an external tool to merge the two.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Question regarding merging branches
Posted by Bill Tutt <ra...@lyra.org>.
> From: Dylan Cuthbert [mailto:dylan@q-games.com]
>
> "Ben Collins-Sussman" <su...@collab.net> wrote in message
> news:86n0qr4bwv.fsf@kepler.ch.collab.net...
> > "Dylan Cuthbert" <dy...@q-games.com> writes:
> > >
> > > What am I not "getting"?
> >
> > Here's what you're not getting: a "conflict" is defined to be a
clash
> > between
> >
> > 1. a patch that the server is trying to apply to a file
> >
> > 2. a local mod that you have made to the file.
> >
> > In your examples, you have *no* local mods when you run 'svn merge',
so
> > you will never ever see a conflict. The patch from the server will
> > always be applied cleanly.
> >
> > Conflicts happen only when there's risk of permanently losing
changes;
> > but because you commit everything, that risk is gone.
> >
> > To get a conflict, try changing the first line to something new,
> > *don't* commit, and run 'svn merge' from the branch to the trunk.
>
> Ok, I understand what you're saying but I'm not sure I agree with the
> methodology.
>
> It seems that this kind of patching will generate bugs because it is
> "piecemeal". ie. parts of the file get updated because there's no
clash,
> and
> other parts don't because there is. However, the parts that do get
> updated
> might rely on the changes in the clashing parts. (as they are all in
the
> same file)
>
> I understand that no data gets lost, but when merging a branch with,
say,
> 100 files or more, all of which have committed changes, some
conflicting,
> some not, I end up with no idea what's been merged and what hasn't.
This
> seems very error-prone.
>
> Or maybe there's some subtlety that I'm missing again. :-)
>
Well, you do know what's been merged, and what generated conflicts.
However, you're not missing anything that no-conflict merges can cause
bugs to happen. Arbitrary text file merging can't prevent bugs like
this. It's just impossible.
Now if we were merging some kind of structured and internally consistent
data structure, you could certainly handle these things much more
sanely. Sadly, no commonly used programming languages are commonly
stored in such a format.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Question regarding merging branches
Posted by Jon Watte <hp...@mindcontrol.org>.
If you don't care about hearing how Perforce does merges, which I
feel works smoother than CVS, then stop here.
> It seems that this kind of patching will generate bugs because it is
> "piecemeal". ie. parts of the file get updated because there's no
> clash, and
> other parts don't because there is. However, the parts that do
> get updated
> might rely on the changes in the clashing parts. (as they are all in the
> same file)
FWIW: when resolving merges, Perforce has the option of "-as" for
"accept safe" (only accept changes to files that only one source has
touched), and "-am" for "accept merged" (accept the piece-by-piece
merge for files where that won't generate conflicts). If there's any
conflict, you can choose interactive edit/resolve, postponing the
resolve until later, or accept a "merge" that inserts conflict
markers containing original, "theirs" and "yours" sections for each
conflict, in-line in the source.
(The default is to ask interactively about each needed merge; you
can argue about whether this is the right thing or not)
I find this works very well. You could do worse than cribbing this :-)
> I understand that no data gets lost, but when merging a branch with, say,
> 100 files or more, all of which have committed changes, some conflicting,
> some not, I end up with no idea what's been merged and what hasn't. This
> seems very error-prone.
Perforce also has the notion of "integrate" (scheduling the work) and
"resolve" (figuring out what to do about each file) as a separate task,
and you can't submit with pending un-resolved integrates. This also
seems to work well, and mimicry ought to be considered :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Ben Collins-Sussman" <su...@collab.net> wrote in message
news:86n0qr4bwv.fsf@kepler.ch.collab.net...
> "Dylan Cuthbert" <dy...@q-games.com> writes:
> >
> > What am I not "getting"?
>
> Here's what you're not getting: a "conflict" is defined to be a clash
> between
>
> 1. a patch that the server is trying to apply to a file
>
> 2. a local mod that you have made to the file.
>
> In your examples, you have *no* local mods when you run 'svn merge', so
> you will never ever see a conflict. The patch from the server will
> always be applied cleanly.
>
> Conflicts happen only when there's risk of permanently losing changes;
> but because you commit everything, that risk is gone.
>
> To get a conflict, try changing the first line to something new,
> *don't* commit, and run 'svn merge' from the branch to the trunk.
Ok, I understand what you're saying but I'm not sure I agree with the
methodology.
It seems that this kind of patching will generate bugs because it is
"piecemeal". ie. parts of the file get updated because there's no clash, and
other parts don't because there is. However, the parts that do get updated
might rely on the changes in the clashing parts. (as they are all in the
same file)
I understand that no data gets lost, but when merging a branch with, say,
100 files or more, all of which have committed changes, some conflicting,
some not, I end up with no idea what's been merged and what hasn't. This
seems very error-prone.
Or maybe there's some subtlety that I'm missing again. :-)
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> I svn copy'd a branch
> I then edited file "A" in that branch, changing the top line to read "clash
> test"
> I then committed
> I then edited the "A" file in the trunk, changing the top line to read
> "conflict central"
> I then committed
> I then edited the "A" file in the branch, changing line 20 or so to read
> "non-conflicting merge"
> I then committed
>
> I am now trying to merge the branch back into the trunk, it is merging
> "non-conflicting merge", but file "A"'s first line reads "conflict central".
> In my mind I should get a conflict or the branches' changes are being
> selectively ignored.
>
> What am I not "getting"?
Here's what you're not getting: a "conflict" is defined to be a clash
between
1. a patch that the server is trying to apply to a file
2. a local mod that you have made to the file.
In your examples, you have *no* local mods when you run 'svn merge', so
you will never ever see a conflict. The patch from the server will
always be applied cleanly.
Conflicts happen only when there's risk of permanently losing changes;
but because you commit everything, that risk is gone.
To get a conflict, try changing the first line to something new,
*don't* commit, and run 'svn merge' from the branch to the trunk.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
version number stuff (was: Question regarding merging branches)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 11, 2002 at 12:53:00AM +0200, Branko Cibej wrote:
> Greg Stein wrote:
>
> >Oh... and I also want to separate the version string into short/long forms.
> >Right now, our Apache server token looks like: SVN/0.14.2 (dev build). That
> >parenthesized portion is highly-nonstandard. We should be putting a "short"
> >form into the signature, and a long form for (say) 'svn --version'
> >
> >
>
> We already have SVN_VER_NUMBER, that does exactly what you want.
Heh. Silly me...
thx,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>Oh... and I also want to separate the version string into short/long forms.
>Right now, our Apache server token looks like: SVN/0.14.2 (dev build). That
>parenthesized portion is highly-nonstandard. We should be putting a "short"
>form into the signature, and a long form for (say) 'svn --version'
>
>
We already have SVN_VER_NUMBER, that does exactly what you want.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 10, 2002 at 11:58:19AM -0700, Justin Erenkrantz wrote:
> On Tue, Sep 10, 2002 at 08:43:28AM -0700, Kevin Pilch-Bisson wrote:
> > Note that Dylan's svn --version output said 0.14.2-dev which is not the same
> > as 0.14.2. The -dev implies that it came from a working copy, not a tarball,
> > so all we can say for sure is that the client was built sometime after 0.14.2.
>
> s/sometime after/sometime before/
>
> The -dev comes before the non-dev version.
>
> Nitpick for sure, but worth clarifying. -- justin
Great nitpick, but it doesn't apply to Subversion :-)
We don't actually have a concept of "in between" like the "-dev" string
symbolizes. It is a real pain in the ass, too, as a version string can say
0.14.2 but it *ISN'T* 0.14.2. The "dev build" thing helps, but foooo...
See, the problem is that we don't bump the version until just before we
release. Thus, we kind of hang out in this 0.14.2 state, and all the
non-release builds say "dev build". Of course, is that dev build exactly
0.14.2, or something later? Who knows.
I've been thinking that we need to patch up our stuff to be similar to
APR(UTIL) and have a -dev concept. We should be able to work in the -dev
thing in conjunction with the "dev build" vs "r3200" stuff when a release is
built.
Hmm. The -dev concept seems a bit orthogonal to the release stuff. I could
see a "0.14.3-dev (r3200)" out there. Or "0.14.3 (r3227)" for a formal
release.
Oh... and I also want to separate the version string into short/long forms.
Right now, our Apache server token looks like: SVN/0.14.2 (dev build). That
parenthesized portion is highly-nonstandard. We should be putting a "short"
form into the signature, and a long form for (say) 'svn --version'
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Sep 10, 2002 at 08:43:28AM -0700, Kevin Pilch-Bisson wrote:
> Note that Dylan's svn --version output said 0.14.2-dev which is not the same
> as 0.14.2. The -dev implies that it came from a working copy, not a tarball,
> so all we can say for sure is that the client was built sometime after 0.14.2.
s/sometime after/sometime before/
The -dev comes before the non-dev version.
Nitpick for sure, but worth clarifying. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Displaying SVN revision number on version info
Posted by Colin D Bennett <cb...@radsoft.com>.
On Tuesday 10 September 2002 08:43 am, Kevin Pilch-Bisson wrote:
> Note that Dylan's svn --version output said 0.14.2-dev which is not the
> same as 0.14.2. The -dev implies that it came from a working copy, not a
> tarball, so all we can say for sure is that the client was built sometime
> after 0.14.2.
Why not show the SVN revision number on the svn --version display? I have no
way of knowing what build of Subversion I'm using unless I put it in a
directory based on the revision, or just try to remember what it was. I've
given it some thought of adding this feature myself, but I thought there
might be a reason it hasn't been done yet, so I wanted to ask ahead of time.
The only downside to this would be if the whole svn wc tree wasn't updated to
the same revision, the number wouldn't indicate the true version, but
otherwise it would. Better than nothing perhaps?
I'm thinking of something like:
Subversion Client, version 0.14.2-r3133 (dev build)
compiled Aug 31 2002, 18:42:47
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Quoting Philip Martin <ph...@codematters.co.uk>:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > > 0.14.2 is rev 3033, so that explains why you have a problem using a
> > > "." path. If you upgrade the problem should be fixed.
> > >
> >
> > Note that Dylan's svn --version output said 0.14.2-dev which is not the
> same
> > as 0.14.2. The -dev implies that it came from a working copy, not a
> tarball,
> > so all we can say for sure is that the client was built sometime after
> 0.14.2.
>
> It says it was compiled on August 23, which is the date of the
> 0.14.2 revision. So even if Dylan is not using 3033, he is using
> something close and I would expect an upgrade to fix the problems he
> had using a "." path.
>
> --
> Philip Martin
>
Again, that would only be the date that version.c got compiled. AFAIK there
is no way to include the time at which the executable was last linked.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Philip Martin <ph...@codematters.co.uk>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > 0.14.2 is rev 3033, so that explains why you have a problem using a
> > "." path. If you upgrade the problem should be fixed.
> >
>
> Note that Dylan's svn --version output said 0.14.2-dev which is not the same
> as 0.14.2. The -dev implies that it came from a working copy, not a tarball,
> so all we can say for sure is that the client was built sometime after 0.14.2.
It says it was compiled on August 23, which is the date of the
0.14.2 revision. So even if Dylan is not using 3033, he is using
something close and I would expect an upgrade to fix the problems he
had using a "." path.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Quoting Philip Martin <ph...@codematters.co.uk>:
> "Dylan Cuthbert" <dy...@q-games.com> writes:
>
> > "Philip Martin" <ph...@codematters.co.uk> wrote in message
> > news:871y83uthv.fsf@codematters.co.uk...
> > >
> > > Are you using a Subversion older than rev 3113? The canonical "."
> > > path handling changed in that version, several bugs like this were
> > > fixed.
> >
> > I'm not sure what version rev. 3113 is, is 0.14.2 newer than it?
>
> 0.14.2 is rev 3033, so that explains why you have a problem using a
> "." path. If you upgrade the problem should be fixed.
>
Note that Dylan's svn --version output said 0.14.2-dev which is not the same
as 0.14.2. The -dev implies that it came from a working copy, not a tarball,
so all we can say for sure is that the client was built sometime after 0.14.2.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
> > "Philip Martin" <ph...@codematters.co.uk> wrote in message
> > news:871y83uthv.fsf@codematters.co.uk...
> 0.14.2 is rev 3033, so that explains why you have a problem using a
> "." path. If you upgrade the problem should be fixed.
Unfortunately, to avoid adding to Microsoft's coffers more than I have to I
don't have a copy of Visual Studio so I can't update it. I'll just wait
until the downloadable binaries are updated.
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Philip Martin <ph...@codematters.co.uk>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> "Philip Martin" <ph...@codematters.co.uk> wrote in message
> news:871y83uthv.fsf@codematters.co.uk...
> >
> > Are you using a Subversion older than rev 3113? The canonical "."
> > path handling changed in that version, several bugs like this were
> > fixed.
>
> I'm not sure what version rev. 3113 is, is 0.14.2 newer than it?
0.14.2 is rev 3033, so that explains why you have a problem using a
"." path. If you upgrade the problem should be fixed.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Philip Martin" <ph...@codematters.co.uk> wrote in message
news:871y83uthv.fsf@codematters.co.uk...
>
> Are you using a Subversion older than rev 3113? The canonical "."
> path handling changed in that version, several bugs like this were
> fixed.
$ svn --version
Subversion Client, version 0.14.2 (dev build)
compiled Aug 23 2002, 19:42:25
Copyright (C) 2000-2002 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
I'm not sure what version rev. 3113 is, is 0.14.2 newer than it?
Regards
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Philip Martin <ph...@codematters.co.uk>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> Now I try the merge again
>
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects .
> svn: Working copy not locked
> svn: directory not locked ()
>
> What does it mean? Something to do with running the cygwin versions of the
> commands?
Are you using a Subversion older than rev 3113? The canonical "."
path handling changed in that version, several bugs like this were
fixed.
>
> Anyway, I continue persevering and discover that if I issue the command from
> the directory above it works *and* I get a conflict at last:
>
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects projects
> C projects/Makefile
>
> However, I have a RIDICULOUS amount of files in the directory now:
>
> $ ls
> Makefile Makefile.63204.00007.tmp
> Makefile.63168.00001.working Makefile.63204.00008.tmp
[...]
> Makefile.63204.00006.tmp
>
>
> Is this normal behaviour or is something screwed up with the cygwin port?
> The docs say that 3 files should exist and they are cleaned up by "svn
> resolve xx". The above files aren't cleaned up when I type svn resolve
> Makefile.
That indicates that a merge has failed several times. If you run the
command 'svn info' on a file that is conflicted you will see the names
of the three conflict files, these are the files that will get removed
when you run 'svn resolve'. If you do something else to resolve the
conflict, say 'svn rm --force' or 'svn revert', these files do not get
deleted. We have to be a little careful about removing these files
automatically, since once they are gone they are not necessarily easy
to reproduce.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
I tried them with the windows native version of svn, same problems, a few
less tmp files were created tho:
Makefile Makefile.64196.00001.r1381
Makefile.64104.00001.working Makefile.64196.00002.r1381
Makefile.64104.00002.working
Makefile.64108.00001.tmp
Makefile.64108.00002.tmp
Makefile.64184.00001.tmp
Makefile.64184.00001.tmp.64096.00001.tmp
Makefile.64184.00001.tmp.64100.00001.tmp
Makefile.64184.00002.tmp
Makefile.64184.00002.tmp.64096.00001.tmp
Makefile.64184.00002.tmp.64100.00001.tmp
Makefile.64192.00001.r1378
Makefile.64192.00002.r1378
Still a helluva lot, but I presume a set of 3 per version? Are they all
necessary to keep around?
I also found the windows native installer, seems to install cygwin's
diff.exe and cygwin1.dll, which is rather annoying if you already have it
installed. (and causes application errors because the dlls are different)
Regards
--
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
"Dylan Cuthbert" <dy...@q-games.com> wrote in message
news:alhpo3$9g1$1@main.gmane.org...
> After more testing, I tried modifying the branch's Makefile again and I
> committed that. The version no. rose to 1381. The trunk's last commit
was
> 1380.
>
> I then go to the trunk's Makefile and type svn update, it says the version
> is 1381.
>
> Now I try the merge again
>
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects .
> svn: Working copy not locked
> svn: directory not locked ()
>
> What does it mean? Something to do with running the cygwin versions of
the
> commands?
>
> Anyway, I continue persevering and discover that if I issue the command
from
> the directory above it works *and* I get a conflict at last:
>
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects projects
> C projects/Makefile
>
> However, I have a RIDICULOUS amount of files in the directory now:
>
> $ ls
> Makefile Makefile.63204.00007.tmp
> Makefile.63168.00001.working Makefile.63204.00008.tmp
> Makefile.63168.00002.working Makefile.63212.00001.tmp
> Makefile.63168.00003.working Makefile.63212.00001.tmp.63192.00001.tmp
> Makefile.63168.00004.working Makefile.63212.00001.tmp.63196.00001.tmp
> Makefile.63168.00005.working Makefile.63212.00002.tmp
> Makefile.63168.00006.working Makefile.63212.00002.tmp.63192.00001.tmp
> Makefile.63168.00007.working Makefile.63212.00002.tmp.63196.00001.tmp
> Makefile.63168.00008.working Makefile.63212.00003.tmp
> Makefile.63168.00009.working Makefile.63212.00003.tmp.63192.00001.tmp
> Makefile.63168.00010.working Makefile.63212.00003.tmp.63196.00001.tmp
> Makefile.63176.00001.r1380 Makefile.63212.00004.tmp
> Makefile.63176.00001.r1381 Makefile.63212.00004.tmp.63192.00001.tmp
> Makefile.63176.00002.r1380 Makefile.63212.00004.tmp.63196.00001.tmp
> Makefile.63176.00002.r1381 Makefile.63212.00005.tmp
> Makefile.63176.00003.r1380 Makefile.63212.00005.tmp.63192.00001.tmp
> Makefile.63176.00003.r1381 Makefile.63212.00005.tmp.63196.00001.tmp
> Makefile.63176.00004.r1381 Makefile.63212.00006.tmp
> Makefile.63176.00005.r1381 Makefile.63212.00006.tmp.63192.00001.tmp
> Makefile.63176.00006.r1381 Makefile.63212.00006.tmp.63196.00001.tmp
> Makefile.63176.00007.r1381 Makefile.63212.00007.tmp
> Makefile.63184.00001.r1377 Makefile.63212.00007.tmp.63192.00001.tmp
> Makefile.63184.00001.r1378 Makefile.63212.00007.tmp.63196.00001.tmp
> Makefile.63184.00002.r1377 Makefile.63212.00008.tmp
> Makefile.63184.00002.r1378 Makefile.63212.00008.tmp.63192.00001.tmp
> Makefile.63184.00003.r1377 Makefile.63212.00008.tmp.63196.00001.tmp
> Makefile.63184.00003.r1378
> Makefile.63184.00004.r1378
> Makefile.63184.00005.r1378
> Makefile.63184.00006.r1378
> Makefile.63184.00007.r1378
> Makefile.63204.00001.tmp
> Makefile.63204.00002.tmp
> Makefile.63204.00003.tmp
> Makefile.63204.00004.tmp
> Makefile.63204.00005.tmp
> Makefile.63204.00006.tmp
>
>
> Is this normal behaviour or is something screwed up with the cygwin port?
> The docs say that 3 files should exist and they are cleaned up by "svn
> resolve xx". The above files aren't cleaned up when I type svn resolve
> Makefile.
>
> Anyway, can someone explain why there is a difference in behaviour between
> using "." and a directory specification?
>
> Regards
>
> ---------------------------------
> Q-Games, Dylan Cuthbert.
> http://www.q-games.com
> P2P internet radio - http://www.peercast.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Ben Collins-Sussman" <su...@collab.net> wrote in message
news:86hegz4bnr.fsf@kepler.ch.collab.net...
> > However, I have a RIDICULOUS amount of files in the directory now:
>
> A conflict should create a single ".working" file and two ".r*"
> files. All of the *.tmp files shouldn't be there; it looks like the
> working copy library got interrupted somehow, repeatedly, and left all
> the .tmp garbage behind. Are you sure this was from a *single* merge
> call?
yes, I did a "ls" beforehand and the files didn't exist. It looks like it
is more of a problem (more files) with the cygwin based svn than the native
windows version, but the problem does exist in both.
--
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects .
> svn: Working copy not locked
> svn: directory not locked ()
Ummm... this looks like a bug in the wc locking stuff. Philip, any
idea what's going on here?
> $ svn merge -r 1378:1381
> http://svnserver/svn/repo/branches/test-branch/projects projects
> C projects/Makefile
>
> However, I have a RIDICULOUS amount of files in the directory now:
A conflict should create a single ".working" file and two ".r*"
files. All of the *.tmp files shouldn't be there; it looks like the
working copy library got interrupted somehow, repeatedly, and left all
the .tmp garbage behind. Are you sure this was from a *single* merge
call?
>
> $ ls
> Makefile Makefile.63204.00007.tmp
> Makefile.63168.00001.working Makefile.63204.00008.tmp
> Makefile.63168.00002.working Makefile.63212.00001.tmp
> Makefile.63168.00003.working Makefile.63212.00001.tmp.63192.00001.tmp
> Makefile.63168.00004.working Makefile.63212.00001.tmp.63196.00001.tmp
> Makefile.63168.00005.working Makefile.63212.00002.tmp
> Makefile.63168.00006.working Makefile.63212.00002.tmp.63192.00001.tmp
> Makefile.63168.00007.working Makefile.63212.00002.tmp.63196.00001.tmp
> Makefile.63168.00008.working Makefile.63212.00003.tmp
> Makefile.63168.00009.working Makefile.63212.00003.tmp.63192.00001.tmp
> Makefile.63168.00010.working Makefile.63212.00003.tmp.63196.00001.tmp
> Makefile.63176.00001.r1380 Makefile.63212.00004.tmp
> Makefile.63176.00001.r1381 Makefile.63212.00004.tmp.63192.00001.tmp
> Makefile.63176.00002.r1380 Makefile.63212.00004.tmp.63196.00001.tmp
> Makefile.63176.00002.r1381 Makefile.63212.00005.tmp
> Makefile.63176.00003.r1380 Makefile.63212.00005.tmp.63192.00001.tmp
> Makefile.63176.00003.r1381 Makefile.63212.00005.tmp.63196.00001.tmp
> Makefile.63176.00004.r1381 Makefile.63212.00006.tmp
> Makefile.63176.00005.r1381 Makefile.63212.00006.tmp.63192.00001.tmp
> Makefile.63176.00006.r1381 Makefile.63212.00006.tmp.63196.00001.tmp
> Makefile.63176.00007.r1381 Makefile.63212.00007.tmp
> Makefile.63184.00001.r1377 Makefile.63212.00007.tmp.63192.00001.tmp
> Makefile.63184.00001.r1378 Makefile.63212.00007.tmp.63196.00001.tmp
> Makefile.63184.00002.r1377 Makefile.63212.00008.tmp
> Makefile.63184.00002.r1378 Makefile.63212.00008.tmp.63192.00001.tmp
> Makefile.63184.00003.r1377 Makefile.63212.00008.tmp.63196.00001.tmp
> Makefile.63184.00003.r1378
> Makefile.63184.00004.r1378
> Makefile.63184.00005.r1378
> Makefile.63184.00006.r1378
> Makefile.63184.00007.r1378
> Makefile.63204.00001.tmp
> Makefile.63204.00002.tmp
> Makefile.63204.00003.tmp
> Makefile.63204.00004.tmp
> Makefile.63204.00005.tmp
> Makefile.63204.00006.tmp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
After more testing, I tried modifying the branch's Makefile again and I
committed that. The version no. rose to 1381. The trunk's last commit was
1380.
I then go to the trunk's Makefile and type svn update, it says the version
is 1381.
Now I try the merge again
$ svn merge -r 1378:1381
http://svnserver/svn/repo/branches/test-branch/projects .
svn: Working copy not locked
svn: directory not locked ()
What does it mean? Something to do with running the cygwin versions of the
commands?
Anyway, I continue persevering and discover that if I issue the command from
the directory above it works *and* I get a conflict at last:
$ svn merge -r 1378:1381
http://svnserver/svn/repo/branches/test-branch/projects projects
C projects/Makefile
However, I have a RIDICULOUS amount of files in the directory now:
$ ls
Makefile Makefile.63204.00007.tmp
Makefile.63168.00001.working Makefile.63204.00008.tmp
Makefile.63168.00002.working Makefile.63212.00001.tmp
Makefile.63168.00003.working Makefile.63212.00001.tmp.63192.00001.tmp
Makefile.63168.00004.working Makefile.63212.00001.tmp.63196.00001.tmp
Makefile.63168.00005.working Makefile.63212.00002.tmp
Makefile.63168.00006.working Makefile.63212.00002.tmp.63192.00001.tmp
Makefile.63168.00007.working Makefile.63212.00002.tmp.63196.00001.tmp
Makefile.63168.00008.working Makefile.63212.00003.tmp
Makefile.63168.00009.working Makefile.63212.00003.tmp.63192.00001.tmp
Makefile.63168.00010.working Makefile.63212.00003.tmp.63196.00001.tmp
Makefile.63176.00001.r1380 Makefile.63212.00004.tmp
Makefile.63176.00001.r1381 Makefile.63212.00004.tmp.63192.00001.tmp
Makefile.63176.00002.r1380 Makefile.63212.00004.tmp.63196.00001.tmp
Makefile.63176.00002.r1381 Makefile.63212.00005.tmp
Makefile.63176.00003.r1380 Makefile.63212.00005.tmp.63192.00001.tmp
Makefile.63176.00003.r1381 Makefile.63212.00005.tmp.63196.00001.tmp
Makefile.63176.00004.r1381 Makefile.63212.00006.tmp
Makefile.63176.00005.r1381 Makefile.63212.00006.tmp.63192.00001.tmp
Makefile.63176.00006.r1381 Makefile.63212.00006.tmp.63196.00001.tmp
Makefile.63176.00007.r1381 Makefile.63212.00007.tmp
Makefile.63184.00001.r1377 Makefile.63212.00007.tmp.63192.00001.tmp
Makefile.63184.00001.r1378 Makefile.63212.00007.tmp.63196.00001.tmp
Makefile.63184.00002.r1377 Makefile.63212.00008.tmp
Makefile.63184.00002.r1378 Makefile.63212.00008.tmp.63192.00001.tmp
Makefile.63184.00003.r1377 Makefile.63212.00008.tmp.63196.00001.tmp
Makefile.63184.00003.r1378
Makefile.63184.00004.r1378
Makefile.63184.00005.r1378
Makefile.63184.00006.r1378
Makefile.63184.00007.r1378
Makefile.63204.00001.tmp
Makefile.63204.00002.tmp
Makefile.63204.00003.tmp
Makefile.63204.00004.tmp
Makefile.63204.00005.tmp
Makefile.63204.00006.tmp
Is this normal behaviour or is something screwed up with the cygwin port?
The docs say that 3 files should exist and they are cleaned up by "svn
resolve xx". The above files aren't cleaned up when I type svn resolve
Makefile.
Anyway, can someone explain why there is a difference in behaviour between
using "." and a directory specification?
Regards
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
Oh this is silly... I'll delete the line from Philip's original mail that's
causing the problem.
"Philip Martin" <ph...@codematters.co.uk> wrote in message
news:87wupzp5et.fsf@codematters.co.uk...
> I suspect the command Dylan wants to run is
>
> *** line deleted ***
>
> where N and M are the revisions before and after the branch change.
> This will merge the change made on the branch into the trunk. A merge
> command using -rN:M only has two arguments becauee the two revisions
> combine with the first argument to provide two URLs.
Hi there,
I tried this, I got a "U Makefile" message, but still no conflicts.
It managed to merge in some non-conflicting lines I had added to the
branched version ok. However the lines I added in right at the top of both
the branch and trunk versions of the file to try and cause a conflict are
nowhere to be seen - the "trunk" version seems to have taken priority for
the conflict.
Here's the order of events again:
I svn copy'd a branch
I then edited file "A" in that branch, changing the top line to read "clash
test"
I then committed
I then edited the "A" file in the trunk, changing the top line to read
"conflict central"
I then committed
I then edited the "A" file in the branch, changing line 20 or so to read
"non-conflicting merge"
I then committed
I then svn merge -r branch_version:latest_version branch-version
trunk-version (local checked-out directories)
I am now trying to merge the branch back into the trunk, it is merging
"non-conflicting merge", but file "A"'s first line reads "conflict central".
In my mind I should get a conflict or the branches' changes are being
selectively ignored.
What am I not "getting"?
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
Very strange.. my message arrived empty - I'll send it again, this is an
exact copy of the message I just sent... it had a "." on an empty line...
something somewhere not escaping the single-dot on a line and causing an
premature "exit" from the SMTP/NNTP post?
"Philip Martin" <ph...@codematters.co.uk> wrote in message
news:87wupzp5et.fsf@codematters.co.uk...
> I suspect the command Dylan wants to run is
>
> $ svn merge -rN:M http://svnserver/svn/repo/branches/test-branch/projects
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Philip Martin" <ph...@codematters.co.uk> wrote in message
news:87wupzp5et.fsf@codematters.co.uk...
> I suspect the command Dylan wants to run is
>
> $ svn merge -rN:M http://svnserver/svn/repo/branches/test-branch/projects
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Colin D Bennett <cb...@radsoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 08 September 2002 05:59 am, Ben Collins-Sussman wrote:
> But the fact that you've "wondered about merging between branches"
> makes me think that you've not read the Subversion Handbook...? Take
> a look in doc/handbook/, or look in the "user docs" section of our
> website's file-sharing area.
I apologize. Thanks for the pointer; this is exactly the kind of thing I'm
looking for. I ran across the Handbook a couple weeks ago, but didn't delve
into it deeply. I will definitely read it in entirety.
- --
Colin D. Bennett <cb...@radsoft.com>
[ RADSoft: Rapid Engineering Specialists ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9e4CxhU94DiH2eqQRAiYtAJ9/Ca1DxCB8E3IxiXP6oaTzPsr8hgCdGzLT
Hu07GhudFaK1ZMHhQD5ICU0=
=7ODE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Dylan Cuthbert <dy...@q-games.com>.
"Colin D Bennett" <cb...@radsoft.com> wrote in message
news:200209071832.39565.cbennett@radsoft.com...
> Currently Subversion does not have direct support for keeping a branch in
sync
> with it's branch point (IOW, automated merging of changes to trunk into
your
> branch). This will be added soon enough, and we will use it when it does
come
> around. In order to merge changes from trunk into your branch:
Is this info in the SVN handbook?
This is what I was assuming was working I think - from a user's point of
view the current merge requires too much pre-requisite information that
should be easily enough taken from the file/directory itself. ie. the last
known common branch point between two files.
Or isn't it that easy with subversion? What if I svn copy a file from that
branch into my trunk before merging, and then modify that file. Now when I
merge, the "-r rev1:rev2" won't work will it? I have to know the files I
have svn copied or moved from elsewhere and merge them all separately? It
seems to me that subversion should be able to find and merge files based on
their common branch points quite easily, but then again I've only briefly
skimmed the technicalities of how subversion works internally.
Regards
--
---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com
P2P internet radio - http://www.peercast.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
Colin D Bennett <cb...@radsoft.com> writes:
> You might find this information useful. I've wondered about merging between
> branches myself, but just this morning I ran across the instructions on the
> Linux1394 project Subversion page and they had a good example, of which I
> attached an excerpt below for your convenience.
Nice simple examples from BenC!
But the fact that you've "wondered about merging between branches"
makes me think that you've not read the Subversion Handbook...? Take
a look in doc/handbook/, or look in the "user docs" section of our
website's file-sharing area.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Colin D Bennett <cb...@radsoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You might find this information useful. I've wondered about merging between
branches myself, but just this morning I ran across the instructions on the
Linux1394 project Subversion page and they had a good example, of which I
attached an excerpt below for your convenience.
- -== ripped from: http://www.linux1394.org/svn.html ==-
Creating a branch or tag
Branches and tags are internally the same to Subversion. Basically a
lightweight copy method. So, it's as easy as:
# svn up
At revision XXX
# svn copy trunk branches/mybranch
# svn propset branch-point XXX branches/mybranch
# svn commit -m "Branched for 'mybranch'" The main difference between tags and
branches is how we use them. Branches are for concurrent lines of development
(e.g. Adding large pieces of funtionality), while tags are just meant to
alias a certain point in the tree.
Currently Subversion does not have direct support for keeping a branch in sync
with it's branch point (IOW, automated merging of changes to trunk into your
branch). This will be added soon enough, and we will use it when it does come
around. In order to merge changes from trunk into your branch:
# svn up
At revision XXX
# svn propget branch-point branches/mybranch
YYY
# svn merge trunk@YYY trunk@XXX branches/mybranch
# svn propset branch-point XXX branches/mybranch
# svn commit -m "Merge changes from trunk to 'mybranch'"
- --
Colin D. Bennett <cb...@radsoft.com>
[ RADSoft: Rapid Engineering Specialists ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9eqi1hU94DiH2eqQRAjdIAJ0Wbx1yHHUl8RV6URyloFuHJGpRVACfQLfW
ar2XhlkvunZ+VSQzH5QrNFQ=
=PGEV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> "Dylan Cuthbert" <dy...@q-games.com> writes:
>
> > I get this when I do a merge:
> >
> > $ svn merge http://svnserver/svn/repo/branches/test-branch/projects . <=
> > note the "."
> > _ Makefile
>
> Hmmmm, it looks like you issued the command correctly. Was your
The merge command above takes three arguments, only two were
explicitly stated so a dot "." was implied as the third, giving
$ svn merge BranchURL . .
The second argument gets converted into an URL giving
$ svn merge BranchURL TrunkURL .
Now this will try to apply the changes between the first and second
arguments, BranchURL and TrunkURL, to the third argument, dot. If the
file in the current directory (in dot) is unmodified, then this merge
is trivial and has no effect. If the file in dot happened to look
like the file BranchURL, it would get transformed into a file like
TrunkURL.
> Makefile changed at all? Run 'svn diff Makefile' to see if it
> received any changes. I suspect that you should have seen an "M"
> instead of a "_" during the merge, and it may just be a display bug.
>
> > Shouldn't I get a conflict to fix?
>
> You should only get a conflict if the Makefile in your working copy
> has *local mods* that conflict with the difference that 'svn merge' is
> trying to fold in. If your working Makefile is unchanged, then poof,
> the differences between the two files will be applied without a
> problem; you'll end up with a Makefile that looks identical to the
> one on the branch.
No, you end up with a Makefile that looks like the one in the current
directory, it's merging a BranchURL-to-TrunkURL diff. You are correct
that a local uncommited change to the file in dot that conflicts with
the BranchURL-to-TrunkURL diff will cause a conflict.
I suspect the command Dylan wants to run is
$ svn merge -rN:M http://svnserver/svn/repo/branches/test-branch/projects .
where N and M are the revisions before and after the branch change.
This will merge the change made on the branch into the trunk. A merge
command using -rN:M only has two arguments becauee the two revisions
combine with the first argument to provide two URLs.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question regarding merging branches
Posted by Ben Collins-Sussman <su...@collab.net>.
"Dylan Cuthbert" <dy...@q-games.com> writes:
> I get this when I do a merge:
>
> $ svn merge http://svnserver/svn/repo/branches/test-branch/projects . <=
> note the "."
> _ Makefile
Hmmmm, it looks like you issued the command correctly. Was your
Makefile changed at all? Run 'svn diff Makefile' to see if it
received any changes. I suspect that you should have seen an "M"
instead of a "_" during the merge, and it may just be a display bug.
> Shouldn't I get a conflict to fix?
You should only get a conflict if the Makefile in your working copy
has *local mods* that conflict with the difference that 'svn merge' is
trying to fold in. If your working Makefile is unchanged, then poof,
the differences between the two files will be applied without a
problem; you'll end up with a Makefile that looks identical to the
one on the branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org