At 1:34 PM +1000 8/22/03, McDonnell, David wrote:
>Thanks for the comments. I left a bit of the history of our in-house
>source control system out. It is currently one folder with a heap of
>files in it, not organised by project or anything like that (which
>obviously has some deficiencies). Sounds like a nightmare I know, and
>hopefully it will change in the future. So for the moment moving single
>files around seems the logical way to go for these legacy files.
It's still the case that Subversion's revision number captures all
the changes that were in a given commit, so if people change three
files in a single commit, you can migrate the commit, intact, with a
merge of that one revision. This saves you having to keep detailed
records on what went into the "change set."
It's also true that "copy" and "merge" might produce different
results, depending on your process and history. Which one you
actually want is something you'll have to decide for yourself.
Simplest case: people always work only on trunk/, and no one ever
migrates a change unless the earlier changes have already been
migrated. This is very likely the basic concept of your process. In
this case, it doesn't matter whether you use copy or merge, you'll
get the same result (it's still easier and more reliable to keep the
change set together by using merge, because that allows you to
specify the particular revision). But maybe your life in reality is
a bit more complicated than the life of your dreams? Mine sure is!
Variation: patching. Maybe after you migrate things and test them,
you find a problem. Maybe you fix that over in migration/, but not
back in trunk/ (or maybe you just haven't got around to fixing it in
trunk/ yet). Now once again, that "important" change comes up;
someone does the work in trunk/ and then wants to migrate it over to
migration/. But, oh dear, there are things in the migration/ copy of
the file that aren't in the trunk/ version. If you simply copy it
over, you lose them, which we assume is evil or they wouldn't have
been done in migration/. In this case, "merge" is exactly what you
want, and it will do a very fine job for you.
Variations: omitted changes. Maybe sometimes a change gets made to
trunk/, but there's some reason not to migrate it. We're not talking
about deciding it was all wrong here, because then you'd just back it
out of trunk. More commonly it's something like: there's a large
change going on, and someone checked in a part of it so others could
work on the rest of it. But there's no point in migrating this much
work; at the best, it's ineffective because the rest isn't there;
possibly, there are some ways in which it breaks things. Now, while
you're in that state, someone makes an important change to one of the
files involved in the partial change. You want the new change; you
don't want the old. What to do, what to do? Answer: if you merge
"-r ImportantChangeRevision", then only the "Important Change" goes
over into migration/; the changes from the partial change are left
behind. This is a very significant advantage of merge over copy.
It's important to admit that this advantage is not 100% perfect: if
some of the "incomplete" work is on the very same lines as some of
the "important" work, then some human will have to get involved to
straighten the mess out.
For example, if the "incomplete" work involved renaming all variables
for some reason, then it would change nearly every line. If
the "important"
work involved changing the value assigned to some variable, then
some lines would be changed in both cases. If you merely merge
the line from trunk/ to migration/, you get one line that sets the new
value into the new name. "New value": good. "New name": bad.
Some human would need to fix the name to match the old style.
In this case, your life may have become so complicated that even
merge won't necessarily notice the problem. Hopefully your compiler
will. But that assumes you're working in a compiled language; if
it's scripts or HTML or other stuff with no automated integrity
checking, then you may be on your own to spot such an event. If you
find yourself in this situation, you really want to use tools like
"svn diff" to compare things while you're making your plan. Even
more important, you want to avoid this sort of situation! The best
way to do that is not to deliver incomplete work to trunk/--put it
into a branch, over in branches/, until it's in a condition that
really can be exposed to everyone in trunk/.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 22 19:18:14 2003