You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ian Eure <ie...@enotes.com> on 2005/09/01 20:57:50 UTC
Merging insanity
Hi. I'm a new SVN user, and I'm having an incredibly hard time
getting merging working right. It's vastly different from how CVS
handles branching and merging, and there's no documentation covering
the differences and how it's supposed to work.
It seems that SVN's merging requires you to know the revision at
which a file was branched, as well as the latest revision in order to
merge. This seems like a lot of work, and I can't believe there isn't
an easier way to say "copy all changes made to this file in branch X
to this file."
Suggestions?
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by "Dale R. Worley" <dw...@pingtel.com>.
On Thu, 2005-09-01 at 13:57 -0700, Ian Eure wrote:
> Hi. I'm a new SVN user, and I'm having an incredibly hard time
> getting merging working right. It's vastly different from how CVS
> handles branching and merging,
That is correct.
> and there's no documentation covering
> the differences and how it's supposed to work.
It itself is fairly well documented in the Subversion book ("Version
Control with Subversion", published by O'Reilly). AFAIK, there is no
documentation "Introduction to Merging with Subversion for CVS Users".
> It seems that SVN's merging requires you to know the revision at
> which a file was branched, as well as the latest revision in order to
> merge.
Yes.
> This seems like a lot of work, and I can't believe there isn't
> an easier way to say "copy all changes made to this file in branch X
> to this file."
>
> Suggestions?
Merging is inherently a complex topic. If you have a fairly simple
source library and only do a few operations, it seems simple to you.
But the whole universe of possible merge operations that people might
want is very large and messy.
It's like a suit of clothes. If you get a tuxedo made by a tailor, it
fits you perfectly and requires no thought. But a rental tuxedo has
many buckles and adjustments, because it will be called on to work for
many people with different requirements. The general solution is more
complicated, and requires more knowledge to use.
IMHO, in the face of this conflict, the Subversion people have made the
right choice, which is to make a tool which can be used for many things,
at the cost of making it harder for any one user. But the reality is
that for any particular "easy way" you could name, somebody on this list
has a situation which it could not be made to serve.
In practice, most of what one wants to do with Subversion merges can be
handled by the "svnmerge" script, which handles most of the details you
are complaining about. You almost certainly want to learn how to use
it.
In addition, I can see by what you write that you haven't thought
merging through, as what you want is "copy all changes made to these
files that were made in branch X *but have not been merged in
before*".
Oops, but not the temporary fix in rev 249!
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Kris Deugau <kd...@vianet.ca>.
Ian Eure wrote:
> "Better" is a subjective term. I feel that it has significant issues
> which make it worse than CVS. And I am most definitely not suffering
> from "branchitis;" I've only created two branches.
Having not used CVS, I can't say if Subversion is "better". But I've
found it quite usable. The ONLY thing I've found troublesome so far is
the occasional need to type long-winded URLs - solved in part by setting
a shell environment variable or using one of several GUI interfaces
(which presumably store the repo URL somewhere internally).
> Perhaps instead of arguing over minutiae, someone would be kind
> enough to explain the usual way for using SVN in the following
> scenario:
I don't know about "the usual way" but I'll describe how I've been
working on a project here. I'll generalize a little (for instance, I
don't often use shell variables for the repo base URL - <Barbie> Dollar
signs are hard! </Barbie>. The project is a web-based system for
managing IP address allocations; it doesn't have any large files (where
by "large" I mean "over 500K"), so some of my methods might not work so
well for you.
> - There is a live setup for production, a staging setup for testing,
> and a dev setup for active development.
For my dev environment, I actually have 3 working copies - one typically
set on repository /trunk, one pointed to /branches/stable (where I keep
the current production code), and a spare for doing merge operations
without mangling work I might have on the go and in a state I consider
"uncommitable".
> - Major work is undertaken on the dev setup
To start a new major feature in my codebase, I do:
$ svn copy $REPOURL/trunk $REPOURL/branches/featurename
That gives me space to work and commit without breaking what's in /trunk
(which isn't *always* comletely functional, but I try to keep it that
way).
I will usually then svn switch my "main" working copy to that branch,
writing code and committing at rather irregular intervals:
$ svn switch $REPOURL/branches/featurefoo
For various reasons, I may switch back to /trunk occasionally and commit
a small thing there.
> - While major work is underway, minor changes may be necessary on the
> production setup
This is where my second working copy comes in; it's a checkout of the
code nominally in production. As I noted above, I keep this code in
/branches/stable in the repo. The "real" production system is also a
checkout of $REPOURL/branches/stable which I can svn update when I've
finished fully merging a new feature or just committing a bugfix into
it.
Bugfixes typically involve one or two lines to be changed in one file.
I have my development system set up such that I can keep browser tabs
open on each of the workspaces, and the "real" production system without
having to monkey with Apache configuration every time I have to switch
from feature development to debugging production code. Or rare occasion
I have to do the debugging on the production server; fortunately not
often.
I *usually* commit bugfixes to /branches/stable, then merge them back to
/trunk; I *rarely* merge them into feature branches. Sometimes I merge
the other way around; I notice something while merging a
newly-completed feature back to the trunk and push that bugfix forward
into the stable code from /trunk. Not consistent but I've gotten into
the habit of logging such merges explicitly: "merge bugfix from /trunk
r1234" or "merge bugfix from /branches/stable r5678". I don't use -m
for the commit message; I *always* let svn commit open an editor so
it's easier to enter multiline log messages.
> - After major dev work is complete, it's moved to the staging setup
> and tested
When I think a new feature is working correctly in its own branch, I'll
move to my third working copy. svn log --stop-on-copy tells me where
the branch was taken from /trunk, and I've only done a partial merge
once that I can recall. I check out /trunk, and then, based on the
revision the branch was created and (usually) the revision number for
the last commit on that branch (taken from the call to svn log):
$ svn merge -r112:456 $REPOURL/branches/featurename .
Which, if I've been careful, merges the new feature seamlessly with
/trunk. Occasionally, there are conflicts. I resolve those and make
sure the code is still working, then I commit that. I include a note
about whether the merge was clean or not in my commit message.
> - Bugs are discovered and fixed
> - Fixed code is moved to the live setup
This is where I do several different things. For some features, I've
just merged all changes from /trunk into /branches/stable. For others,
for whatever reason (not wanting other changes that I've applied to
/trunk in the meantime, for instance), I'll merge from the feature
branch. In both cases, I'll use pretty much the same procedure as
above.
All of this could be done with a single working copy, but between the
fact that I sometimes need to bugfix on the run while in the middle of
developing a new feature, and the fact that my development space tends
to get a bit messy (not to mention my 1M working copies <g>); I found
it simpler to keep multiple working copies pointed to various different
repo URLs.
Occasionally I will create a tag for some stage of code that I feel
should be noted a little more prominently; svn copy -r4321
$REPOURL/trunk $REPOURL/tags/tagname does that just fine.
-kgd
--
Get your mouse off of there! You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 2, 2005, at 11:10 AM, John Allen wrote:
> On Thursday 01 September 2005 23:56, Ian Eure wrote:
>
>> On Sep 1, 2005, at 3:23 PM, Ben Collins-Sussman wrote:
>>
>>> Is all the fuss about trying to find the revision which is the
>>> 'base' of the branch? The whole running 'svn log --stop-on-copy'
>>> to figure out when the branch was created?
>>>
>>> Why not, when creating the branch, also make a tag of it:
>>>
>>> $ svn cp trunkURL branchURL
>>> $ svn cp branchURL branch-beginning-tag-URL
>>>
>>> [...make changes on branch...]
>>>
>>> $ svn checkout trunkURL; cd trunk
>>> $ svn merge branch-beginning-tag-URL branchURL
>>>
>>
>> Still too much work. And I believe you omitted the delete/recreate
>> step for thee branch-beginning tag, which is still more work. And
>> creating new tags/branches slooooooow.
>>
>>
>
> Creating tags, and branches in SVN is super fast. Just make sure
> you use URLs
> to create, don't do the copy locally.
>
> eg.
> svn copy -q -m "Branch for mad changes" svn://svn/repo/admin/main
> svn://svn/repo/admin/tags/release-1.0.41.0
>
> Happens more or less instantly. The switch your working copy to
> that tag with
> svn switch
> svn switch svn://svn/repo/admin/tags/release-1.0.41.0
>
>
>
>> But this is my point - Subversion knows (or should know) the revision
>> at which a branch was created, so why is all this screwing around
>> with revision numbers and tags necessary in the first place?
>>
>>
>
> You are suffering from 2 problems
> 1. SVN is just a better CVS. It is better but it is also different,
> you need
> to learn how it works best, not make it work live CVS
> 2. You are suffering from branchitis. You are clearly creating
> branches willy
> nilly, and this is a recipe for disaster.
>
> I only create branches from release tags, that way I can always see
> the diffs
> between the branch, and the release. Also when I release from a
> branch I just
> increment the last number in the rev, so I can clearly see it is a
> branch
> release.
>
"Better" is a subjective term. I feel that it has significant issues
which make it worse than CVS. And I am most definitely not suffering
from "branchitis;" I've only created two branches.
Perhaps instead of arguing over minutiae, someone would be kind
enough to explain the usual way for using SVN in the following scenario:
- There is a live setup for production, a staging setup for testing,
and a dev setup for active development.
- Major work is undertaken on the dev setup
- While major work is underway, minor changes may be necessary on the
production setup
- After major dev work is complete, it's moved to the staging setup
and tested
- Bugs are discovered and fixed
- Fixed code is moved to the live setup
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by John Allen <jo...@dublinux.net>.
On Thursday 01 September 2005 23:56, Ian Eure wrote:
> On Sep 1, 2005, at 3:23 PM, Ben Collins-Sussman wrote:
> > Is all the fuss about trying to find the revision which is the
> > 'base' of the branch? The whole running 'svn log --stop-on-copy'
> > to figure out when the branch was created?
> >
> > Why not, when creating the branch, also make a tag of it:
> >
> > $ svn cp trunkURL branchURL
> > $ svn cp branchURL branch-beginning-tag-URL
> >
> > [...make changes on branch...]
> >
> > $ svn checkout trunkURL; cd trunk
> > $ svn merge branch-beginning-tag-URL branchURL
>
> Still too much work. And I believe you omitted the delete/recreate
> step for thee branch-beginning tag, which is still more work. And
> creating new tags/branches slooooooow.
>
Creating tags, and branches in SVN is super fast. Just make sure you use URLs
to create, don't do the copy locally.
eg.
svn copy -q -m "Branch for mad changes" svn://svn/repo/admin/main
svn://svn/repo/admin/tags/release-1.0.41.0
Happens more or less instantly. The switch your working copy to that tag with
svn switch
svn switch svn://svn/repo/admin/tags/release-1.0.41.0
> But this is my point - Subversion knows (or should know) the revision
> at which a branch was created, so why is all this screwing around
> with revision numbers and tags necessary in the first place?
>
You are suffering from 2 problems
1. SVN is just a better CVS. It is better but it is also different, you need
to learn how it works best, not make it work live CVS
2. You are suffering from branchitis. You are clearly creating branches willy
nilly, and this is a recipe for disaster.
I only create branches from release tags, that way I can always see the diffs
between the branch, and the release. Also when I release from a branch I just
increment the last number in the rev, so I can clearly see it is a branch
release.
> --
> Ian Eure
> Developer,
> eNotes.com LLC
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
John Allen, mailto:john.allen@dublinux.net
MandrakeClub Silver Member. http://www.dublinux.net
Site of the day: http://www.kde.ie/
Mandrakelinux release 10.2 (Cooker) for i586, kernel 2.6.11-6mdk
19:04:09 up 1:25, 5 users, load average: 0.02, 0.04, 0.00
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by David Gómez <da...@pleyades.net>.
Hi,
On Sep 01 at 05:23:00, Ben Collins-Sussman wrote:
> >You're not the only one, I've heard one of my fellow developers fuming
> >about this difference between CVS and SVN. I think, for now at least,
> >he's worked around it by writing wrapper scripts.
>
> Is all the fuss about trying to find the revision which is the 'base'
> of the branch? The whole running 'svn log --stop-on-copy'
Something that could be easily solved if subversion allowed revision numbers
to be associated to mnemonic manes...
> $ svn cp branchURL branch-beginning-tag-URL
And avoid this...
regards,
--
David Gómez Jabber ID: davidge@jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ryan Schmidt <su...@ryandesign.com>.
Let's keep replies on the list so others can benefit too.
On Sep 2, 2005, at 18:31, Ian Eure wrote:
> On Sep 2, 2005, at 7:58 AM, Ryan Schmidt wrote:
>
>> The only insanity I see here is having a checkout of the trunk and
>> all branches. Yes, absolutely, if your working copy is ~500MB (you
>> didn't say; you only mentioned repository size, which is not
>> relevant here), then copying it to a new location on your hard
>> drive will need to create ~1GB of new data (the .svn directories
>> contain another copy of the data), and that could be very very
>> slow, depending on your client's filesystem.
>>
>> Is there a specific reason why you feel you should have a checkout
>> of all of this? The usual way is to have working copy of trunk
>> only, and do your work there. You can "svn switch" to a branch
>> when you need it. Creating branches and tags is also usually done
>> via URL, as shown abvoe.
>>
>
> Because it's precisely what's stated in the Subversion book:
> "Making a copy is now simply a matter of passing two working-copy
> paths to the svn copy command:"
>
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-2.1
>
Did you read the sentence a little above it?
"We'll demonstrate the messy way first, just to make the concept clear."
And the one a little below it?
"And now the easier method of creating a branch, which we should have
told you about in the first place: svn copy is able to operate
directly on two URLs."
> Also, it's vastly easier to manage working directories instead of
> using the more cumbersome full URLs.
>
Nothing particularly difficult about managing URLs. I define a shell
environment variable for my project:
export PROJ=https://www.example.com/svn/project1
Then I can create a branch like this:
svn cp $PROJ/trunk $PROJ/branches/1.2 -m "Creating 1.2 branch from
trunk"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ryan Schmidt <su...@ryandesign.com>.
>> SVN. I have a 506mb repo, and it takes around an hour to create a
>> new branch.
>> I haven't tried a tag, but since branches and tags Are Just
>> Directories, I
>> assume it will be no different.
>>
>> I'm doing:
>> $ svn copy trunk branches/new-branch; svn ci -m 'created new branch'
>> branches/new-branch
>
> Try
>
> $svn copy trunkURL branchURL/new-branch
>
> (no checkout required. no commit required)
> If this takes you an hour (in fact, if it takes more than a second or
> two), then there is something seriously wrong with the installation.
>
> Also, I thought even the above method Ian is using should have been
> very fast. I have never tried it though. Someone else in the group can
> comment on it?
The only insanity I see here is having a checkout of the trunk and
all branches. Yes, absolutely, if your working copy is ~500MB (you
didn't say; you only mentioned repository size, which is not relevant
here), then copying it to a new location on your hard drive will need
to create ~1GB of new data (the .svn directories contain another copy
of the data), and that could be very very slow, depending on your
client's filesystem.
Is there a specific reason why you feel you should have a checkout of
all of this? The usual way is to have working copy of trunk only, and
do your work there. You can "svn switch" to a branch when you need
it. Creating branches and tags is also usually done via URL, as shown
abvoe.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Hari Kodungallur <hk...@gmail.com>.
On 9/2/05, Hari Kodungallur <hk...@gmail.com> wrote:
> That's where you get into periodic merges. You will need to keep track
> of merges. Unless you are coming from the clearcase world, you are not
> used to merge tracking anyway.
>
I meant "...you are not used to the tool doing the merge tracking..."
-Hari
SpikeSource Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Blair Zajac <bl...@orcaware.com>.
Hari Kodungallur wrote:
> That's where you get into periodic merges. You will need to keep track
> of merges. Unless you are coming from the clearcase world, you are not
> used to merge tracking anyway.
To help out with keeping track of merging, which Subversion doesn't do
itself that well, check out svnmerge. It helps manage the revisions
that have been already merged from one location to another. You don't
have to remember revision numbers.
http://svn.collab.net/repos/svn/trunk/contrib/client-side/
There's a mailing list for this tool at
http://www.orcaware.com/mailman/listinfo/svnmerge
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Hari Kodungallur <hk...@gmail.com>.
On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
> On Thursday 01 September 2005 04:52 pm, you wrote:
> > On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
> > > On Sep 1, 2005, at 3:23 PM, Ben Collins-Sussman wrote:
> > > > Is all the fuss about trying to find the revision which is the
> > > > 'base' of the branch? The whole running 'svn log --stop-on-copy'
> > > > to figure out when the branch was created?
> > > >
> > > > Why not, when creating the branch, also make a tag of it:
> > > >
> > > > $ svn cp trunkURL branchURL
> > > > $ svn cp branchURL branch-beginning-tag-URL
> > > >
> > > > [...make changes on branch...]
> > > >
> > > > $ svn checkout trunkURL; cd trunk
> > > > $ svn merge branch-beginning-tag-URL branchURL
> > >
> > > Still too much work. And I believe you omitted the delete/recreate
> > > step for thee branch-beginning tag, which is still more work.
> >
> > I am not sure about delete/recreate. There was no discussion about
> > that. As for the creation of the branch-beginning tag, thats what you
> > would do in CVS -- you will have to create a branch-tag first and then
> > create the branch and then merge. Same number of steps.
> >
> It's that way in the FAQ:
> http://subversion.tigris.org/faq.html#merge-using-tags
>
> You most definitely do not have to create additional tags to use CVS like
> this. You simply create the branch, and merge changes from HEAD (or another)
> branch into the working copy.
>
>
> > > And creating new tags/branches [is] slooooooow.
> >
> > Are you talking about CVS or SVN?
> > If you are talking about SVN, then you have not read the book or tried
> > out branching examples yet. Apart from atomic commits, the best thing
> > I like about SVN is that it branches/tags in a snap. Try it out. I am
> > sure you will love it.
> >
> SVN. I have a 506mb repo, and it takes around an hour to create a new branch.
> I haven't tried a tag, but since branches and tags Are Just Directories, I
> assume it will be no different.
>
> I'm doing:
> $ svn copy trunk branches/new-branch; svn ci -m 'created new branch'
> branches/new-branch
Try
$svn copy trunkURL branchURL/new-branch
(no checkout required. no commit required)
If this takes you an hour (in fact, if it takes more than a second or
two), then there is something seriously wrong with the installation.
Also, I thought even the above method Ian is using should have been
very fast. I have never tried it though. Someone else in the group can
comment on it?
>
> Which is exactly what the manual states.
>
> It's not a snap, and I don't love it.
>
>
> > > But this is my point - Subversion knows (or should know) the revision
> > > at which a branch was created, so why is all this screwing around
> > > with revision numbers and tags necessary in the first place?
> >
> > This is because subversion can not assume that the user wants to merge
> > every change from the branch. You might want to merge only some
> > changes from the branch (as in periodic merges -- now, now, don't tell
> > me that its a lot more work to do periodic merges in SVN. it has been
> > flagged in the book and it also provides suggestions to handle such
> > situations).
> >
> I never said it should assume anything, but rather that it should know the
> correct revision to apply changes from in this scenario. I.e. if you omitted
> the revision, or explicitly requested it via a pseudo 'LASTCOPY' revision,
> instead of having to look up the correct revision by hand.
>
> It wouldn't be an issue if you could just say "merge the most recent changes
> from file or directory X in branch Y into the same file or directory in this
> branch," but you can't. You have to fool around with revision numbers, or
> tags, or whatever.
>
That's where you get into periodic merges. You will need to keep track
of merges. Unless you are coming from the clearcase world, you are not
used to merge tracking anyway.
-Hari
SpikeSource Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Branko Čibej <br...@xbc.nu>.
On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
> I'm doing:
> $ svn copy trunk branches/new-branch; svn ci -m 'created new branch'
> branches/new-branch
I can't muster even a smidgeon of sympathy for people who obviously
haven't read our Book, then come complaining here about nonsense it
would've taken them 5 minutes to solve if they _had_ read it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Branko Čibej <br...@xbc.nu>.
Ian Eure wrote:
> And creating new tags/branches slooooooow.
Eh? What on earth are you doing? Creating a tag or branch on the server
is a constant-time operation, regardless of the size of your repository.
It's not slow. it is in fact blindlingly fast compared to most other
version control systems I've ever used.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Hari Kodungallur <hk...@gmail.com>.
On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
> On Sep 1, 2005, at 3:23 PM, Ben Collins-Sussman wrote:
> >
> > Is all the fuss about trying to find the revision which is the
> > 'base' of the branch? The whole running 'svn log --stop-on-copy'
> > to figure out when the branch was created?
> >
> > Why not, when creating the branch, also make a tag of it:
> >
> > $ svn cp trunkURL branchURL
> > $ svn cp branchURL branch-beginning-tag-URL
> >
> > [...make changes on branch...]
> >
> > $ svn checkout trunkURL; cd trunk
> > $ svn merge branch-beginning-tag-URL branchURL
>
> Still too much work. And I believe you omitted the delete/recreate
> step for thee branch-beginning tag, which is still more work.
I am not sure about delete/recreate. There was no discussion about
that. As for the creation of the branch-beginning tag, thats what you
would do in CVS -- you will have to create a branch-tag first and then
create the branch and then merge. Same number of steps.
> And creating new tags/branches slooooooow.
Are you talking about CVS or SVN?
If you are talking about SVN, then you have not read the book or tried
out branching examples yet. Apart from atomic commits, the best thing
I like about SVN is that it branches/tags in a snap. Try it out. I am
sure you will love it.
>
> But this is my point - Subversion knows (or should know) the revision
> at which a branch was created, so why is all this screwing around
> with revision numbers and tags necessary in the first place?
>
This is because subversion can not assume that the user wants to merge
every change from the branch. You might want to merge only some
changes from the branch (as in periodic merges -- now, now, don't tell
me that its a lot more work to do periodic merges in SVN. it has been
flagged in the book and it also provides suggestions to handle such
situations).
-Hari
SpikeSource Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 1, 2005, at 3:23 PM, Ben Collins-Sussman wrote:
>
> Is all the fuss about trying to find the revision which is the
> 'base' of the branch? The whole running 'svn log --stop-on-copy'
> to figure out when the branch was created?
>
> Why not, when creating the branch, also make a tag of it:
>
> $ svn cp trunkURL branchURL
> $ svn cp branchURL branch-beginning-tag-URL
>
> [...make changes on branch...]
>
> $ svn checkout trunkURL; cd trunk
> $ svn merge branch-beginning-tag-URL branchURL
Still too much work. And I believe you omitted the delete/recreate
step for thee branch-beginning tag, which is still more work. And
creating new tags/branches slooooooow.
But this is my point - Subversion knows (or should know) the revision
at which a branch was created, so why is all this screwing around
with revision numbers and tags necessary in the first place?
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 7, 2005, at 2:37 PM, Adam Gibson wrote:
> Dale R. Worley wrote:
>
>> On Wed, 2005-09-07 at 12:11 -0400, Adam Gibson wrote:
>>
>>> Would the concern with implementing CREATED be that everyone
>>> might think that would work for all branching methods and cause
>>> confusion?
>>>
>> The problem runs deeper than that -- you've described what you want
>> CREATED to in a very limited (albeit useful) set of
>> circumstances. But
>> you haven't given a specification that explains how CREATED is
>> interpreted in *all* possible circumstances, nor an algorithm that
>> shows
>> how that could be implmented. To do those things, you have to
>> deal with
>> all the dank corners of what might be going on.
>> For instance, does each file and directory carry a value of
>> CREATED? In
>> a WC, which item's CREATED controls how the command is executed?
>> If you
>> use multiple stages of branching, how does CREATED help? Etc., etc.
>> Dale
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
> My limited understanding of SVN internals and svn lingo will
> probably mean my input on this will be rather limited but here goes
> an attempt to try and explain at least the basics.
>
> - The CREATED tag name would be something assigned to every file
> and directory and would be assigned to represent the revision
> number that the file was created by an import, copy, or move.
> - Any reference to CREATED by -r or @ would use the revision number
> that was stored for the file or directory that was referenced. If
> the URL is pointing to a file then the files CREATED revision is
> referenced or if a directory is referenced then the directories
> CREATED revision is used.
>
I would add:
- In the case that the file was created with `copy,' CREATED would be
the version which the copy was created from. E.g. version at 1, file
is copied, new version is 2. CREATED would be r1.
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Adam Gibson <ag...@ptm.com>.
Dale R. Worley wrote:
> On Wed, 2005-09-07 at 12:11 -0400, Adam Gibson wrote:
>
>>Would the concern with implementing CREATED be that everyone might think
>>that would work for all branching methods and cause confusion?
>
>
> The problem runs deeper than that -- you've described what you want
> CREATED to in a very limited (albeit useful) set of circumstances. But
> you haven't given a specification that explains how CREATED is
> interpreted in *all* possible circumstances, nor an algorithm that shows
> how that could be implmented. To do those things, you have to deal with
> all the dank corners of what might be going on.
>
> For instance, does each file and directory carry a value of CREATED? In
> a WC, which item's CREATED controls how the command is executed? If you
> use multiple stages of branching, how does CREATED help? Etc., etc.
>
> Dale
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
My limited understanding of SVN internals and svn lingo will probably
mean my input on this will be rather limited but here goes an attempt to
try and explain at least the basics.
- The CREATED tag name would be something assigned to every file and
directory and would be assigned to represent the revision number that
the file was created by an import, copy, or move.
- Any reference to CREATED by -r or @ would use the revision number that
was stored for the file or directory that was referenced. If the URL is
pointing to a file then the files CREATED revision is referenced or if a
directory is referenced then the directories CREATED revision is used.
I wonder if it would be possible for the server to do a --stop-on-copy
itself any time it gets a CREATED revision name somehow instead of
storing a CREATED attribute for every file.
Too many questions than answers I guess.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by "Dale R. Worley" <dw...@pingtel.com>.
On Wed, 2005-09-07 at 12:11 -0400, Adam Gibson wrote:
> Would the concern with implementing CREATED be that everyone might think
> that would work for all branching methods and cause confusion?
The problem runs deeper than that -- you've described what you want
CREATED to in a very limited (albeit useful) set of circumstances. But
you haven't given a specification that explains how CREATED is
interpreted in *all* possible circumstances, nor an algorithm that shows
how that could be implmented. To do those things, you have to deal with
all the dank corners of what might be going on.
For instance, does each file and directory carry a value of CREATED? In
a WC, which item's CREATED controls how the command is executed? If you
use multiple stages of branching, how does CREATED help? Etc., etc.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Adam Gibson <ag...@ptm.com>.
Dale R. Worley wrote:
> On Tue, 2005-09-06 at 14:15 -0700, Ian Eure wrote:
>
>>>I never really understood why someone didn't think to program in a
>>>CREATED revision name to make things more user-friendly for that
>>>use instead of needing to create and delete tags.
>>>
>>>svn merge -rCREATED:HEAD branchURL .
>>>
>>>CREATED would be assigned to the newly created files/directories at
>>>the time when the copy/move was performed.
>>>
>>>I know it would make things easier for training other users around
>>>me how to merge.
>>>
>>
>>Precisely. This would alleviate my biggest problem with SVN's branch/
>>merge operations. I think that requiring a revision lookup or tag to
>>merge changes is difficult and stupid.
>
>
> It's not as easy as it looks, because a "branch" is only an idea in the
> users' heads, not a feature of the Subversion repository. There is no
> uniquely defined "created" revision if you assemble a new subtree out of
> copies from various different revs and locations in the repository.
>
> Can you come up with a clean, sensible definition of "CREATED" that does
> what you want?
>
> Dale
>
I understand that not everyone uses a branch in the same way. Having a
CREATED tag name would not solve branching for everyone as it would
mainly help for the people who branch from trunk and keep only the
changes since the trunk copy on the branch(and make sure never to copy
the branch again during the branch life). I do not know the stats on
how many people use svn in that way but that is the norm for my uses.
Would the concern with implementing CREATED be that everyone might think
that would work for all branching methods and cause confusion?
One other feature to consider for CREATED is to implement a command line
switch to 'copy' that would cause the CREATED revision name to not get
updated to the latest revision of the copy if a commandline switch was
passed --copy-created-time (ok that is a bad name but you get the idea).
This would allow people working on a branch to copy it without setting
the CREATED on the files copied to the current revision. This might be
even more confusing for people not used to it though because they might
think CREATED always means when the last copy was done for that
file/directory.
Just having the CREATED feature itself would be a big time saver for
people who branch the way explained above. It just makes things easier
without compromising anything. People who branch differently just would
not use the CREATED revision name feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by "Dale R. Worley" <dw...@pingtel.com>.
On Tue, 2005-09-06 at 14:15 -0700, Ian Eure wrote:
> > I never really understood why someone didn't think to program in a
> > CREATED revision name to make things more user-friendly for that
> > use instead of needing to create and delete tags.
> >
> > svn merge -rCREATED:HEAD branchURL .
> >
> > CREATED would be assigned to the newly created files/directories at
> > the time when the copy/move was performed.
> >
> > I know it would make things easier for training other users around
> > me how to merge.
> >
> Precisely. This would alleviate my biggest problem with SVN's branch/
> merge operations. I think that requiring a revision lookup or tag to
> merge changes is difficult and stupid.
It's not as easy as it looks, because a "branch" is only an idea in the
users' heads, not a feature of the Subversion repository. There is no
uniquely defined "created" revision if you assemble a new subtree out of
copies from various different revs and locations in the repository.
Can you come up with a clean, sensible definition of "CREATED" that does
what you want?
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 6, 2005, at 8:12 AM, Adam Gibson wrote:
> Ben Collins-Sussman wrote:
>
> I never really understood why someone didn't think to program in a
> CREATED revision name to make things more user-friendly for that
> use instead of needing to create and delete tags.
>
> svn merge -rCREATED:HEAD branchURL .
>
> CREATED would be assigned to the newly created files/directories at
> the time when the copy/move was performed.
>
> I know it would make things easier for training other users around
> me how to merge.
>
Precisely. This would alleviate my biggest problem with SVN's branch/
merge operations. I think that requiring a revision lookup or tag to
merge changes is difficult and stupid.
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Adam Gibson <ag...@ptm.com>.
Ben Collins-Sussman wrote:
>
> Is all the fuss about trying to find the revision which is the 'base'
> of the branch? The whole running 'svn log --stop-on-copy' to figure
> out when the branch was created?
>
> Why not, when creating the branch, also make a tag of it:
>
> $ svn cp trunkURL branchURL
> $ svn cp branchURL branch-beginning-tag-URL
>
> [...make changes on branch...]
>
> $ svn checkout trunkURL; cd trunk
> $ svn merge branch-beginning-tag-URL branchURL
I never really understood why someone didn't think to program in a
CREATED revision name to make things more user-friendly for that use
instead of needing to create and delete tags.
svn merge -rCREATED:HEAD branchURL .
CREATED would be assigned to the newly created files/directories at the
time when the copy/move was performed.
I know it would make things easier for training other users around me
how to merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ben Collins-Sussman <su...@collab.net>.
Did you mean to mail me privately (four times?) rather than the whole
list?
On Sep 1, 2005, at 7:05 PM, Clemens Schwaighofer wrote:
>
> But what if I branch out, do changes, merge them back, do some more
> changes, etc.
>
> I wished svn would know, when I last merged what with what, so the
> next time he "knows" what to take to merge my branch changes back.
>
> eg if I have trunk and branch I would love to do:
>
> #> svn merge trunkURL branchURL
>
> and he does it all for me. He knows what was already merged, etc.
>
>
Yes, congrats, you've just described merge-tracking, the holy grail
of version control. You don't need to convince anyone here that it's
good/useful/desired/important. It's that huge mountain in the
distance on our roadmap.
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 1, 2005, at 5:11 PM, Ximon Eighteen wrote:
>>> do you think this is a lot of work?
>>>
>>>
>> Yes, it's too much work, and it hinges upon fallible human decisions.
>> Is there really no simple equivalent to `cvs update -j MY_BRANCH' in
>> Subversion?
>>
>
> You're not the only one, I've heard one of my fellow developers fuming
> about this difference between CVS and SVN. I think, for now at least,
> he's worked around it by writing wrapper scripts.
Is all the fuss about trying to find the revision which is the 'base'
of the branch? The whole running 'svn log --stop-on-copy' to figure
out when the branch was created?
Why not, when creating the branch, also make a tag of it:
$ svn cp trunkURL branchURL
$ svn cp branchURL branch-beginning-tag-URL
[...make changes on branch...]
$ svn checkout trunkURL; cd trunk
$ svn merge branch-beginning-tag-URL branchURL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Raman Gupta <ro...@fastmail.fm>.
Ian Eure wrote:
> On Sep 1, 2005, at 3:11 PM, Ximon Eighteen wrote:
>
>>>> do you think this is a lot of work?
>>>>
>>>>
>>> Yes, it's too much work, and it hinges upon fallible human decisions.
>>> Is there really no simple equivalent to `cvs update -j MY_BRANCH' in
>>> Subversion?
CVS requires the same fallible human decisions -- you always need to tag
your branches so that you know where the branch point was, and if you've
already merged from that branch, where the last merge point was.
>> You're not the only one, I've heard one of my fellow developers fuming
>> about this difference between CVS and SVN. I think, for now at least,
>> he's worked around it by writing wrapper scripts.
>>
>> On this topic I think he also defines a variable for the base part of
>> the repository URL that doesn't change between commands so that he
>> doesn't have to retype it every time he needs it.
>
>
> Is there any way you could get me in touch with him, or send me those
> scripts?
Why don't you try out svnmerge, which is a great bourne shell script
that really helps with automating merging. Unfortunately, the main
svnmerge web site is down right now, but you can get the script from the
subversion repository:
http://svn.collab.net/viewcvs/svn/trunk/contrib/client-side/svnmerge?rev=HEAD&view=log
Some information about it here (I think this page has most of the
information that was on the main page):
http://www.sipfoundry.org/tools/svnmerge.html
Also check out the new svnmerge mailing list:
http://www.orcaware.com/mailman/listinfo/svnmerge
If you're interested in bi-directional merging of branches, check out
the August list archives, where there was some very interesting
discussion on this topic (including a working patch, though Archie has
decided that the final implementation of this will work differently).
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 1, 2005, at 3:11 PM, Ximon Eighteen wrote:
>>> do you think this is a lot of work?
>>>
>>>
>> Yes, it's too much work, and it hinges upon fallible human decisions.
>> Is there really no simple equivalent to `cvs update -j MY_BRANCH' in
>> Subversion?
>>
>
> You're not the only one, I've heard one of my fellow developers fuming
> about this difference between CVS and SVN. I think, for now at least,
> he's worked around it by writing wrapper scripts.
>
> On this topic I think he also defines a variable for the base part of
> the repository URL that doesn't change between commands so that he
> doesn't have to retype it every time he needs it.
Is there any way you could get me in touch with him, or send me those
scripts?
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ximon Eighteen <xi...@int.greenpeace.org>.
>> do you think this is a lot of work?
>>
> Yes, it's too much work, and it hinges upon fallible human decisions.
> Is there really no simple equivalent to `cvs update -j MY_BRANCH' in
> Subversion?
You're not the only one, I've heard one of my fellow developers fuming
about this difference between CVS and SVN. I think, for now at least,
he's worked around it by writing wrapper scripts.
On this topic I think he also defines a variable for the base part of
the repository URL that doesn't change between commands so that he
doesn't have to retype it every time he needs it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Ian Eure <ie...@enotes.com>.
On Sep 1, 2005, at 2:16 PM, Hari Kodungallur wrote:
> On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
>
>> Hi. I'm a new SVN user, and I'm having an incredibly hard time
>> getting merging working right. It's vastly different from how CVS
>> handles branching and merging, and there's no documentation covering
>> the differences and how it's supposed to work.
>>
>> It seems that SVN's merging requires you to know the revision at
>> which a file was branched, as well as the latest revision in order to
>> merge. This seems like a lot of work, and I can't believe there isn't
>> an easier way to say "copy all changes made to this file in branch X
>> to this file."
>>
>> Suggestions?
>>
>>
>
> svn log --stop-on-copy <url to branch X>
>
> the last entry of the log will be the revision at which you branched.
> Lets say this number is N
>
> svn merge N:HEAD <url to branch X>
>
> this will merge all changes made in the branch to your working copy
> (note: if you merging to trunk, your working copy is trunk)
>
> do you think this is a lot of work?
>
Yes, it's too much work, and it hinges upon fallible human decisions.
Is there really no simple equivalent to `cvs update -j MY_BRANCH' in
Subversion?
Also, what about merging changes back from a branch into trunk? Since
trunk is likely to have been branched many times, how does one figure
out the correct revision to use in the merge command?
--
Ian Eure
Developer,
eNotes.com LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging insanity
Posted by Hari Kodungallur <hk...@gmail.com>.
On 9/1/05, Ian Eure <ie...@enotes.com> wrote:
> Hi. I'm a new SVN user, and I'm having an incredibly hard time
> getting merging working right. It's vastly different from how CVS
> handles branching and merging, and there's no documentation covering
> the differences and how it's supposed to work.
>
> It seems that SVN's merging requires you to know the revision at
> which a file was branched, as well as the latest revision in order to
> merge. This seems like a lot of work, and I can't believe there isn't
> an easier way to say "copy all changes made to this file in branch X
> to this file."
>
> Suggestions?
>
svn log --stop-on-copy <url to branch X>
the last entry of the log will be the revision at which you branched.
Lets say this number is N
svn merge N:HEAD <url to branch X>
this will merge all changes made in the branch to your working copy
(note: if you merging to trunk, your working copy is trunk)
do you think this is a lot of work?
-Hari
SpikeSource Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org