Ok, now we're getting somewhere. If I can do this on a per-file
basis then that's not quite so bad; it wasn't clear to me from the
documentation that this was possible.
It's still not ideal; it's much more convenient to do "cvs tag -F
stable x.java, x.html, x.js" than it is to look up and use a revision
number. But I suppose I can live with that.
I don't have a problem with committing related changes together, and
not mixing several changes into a single commit. I generally do
things this way now, to keep my commit messages on message, so to
speak. :) But I also know that I occasionally have a brain fart and
forget to list the filenames, leading to everything in the current
directory and below getting committed. Assuming svn works the same
way the same thing can happen, so we can't completely rule out having
to do that. However, it seems like the above would work in either case.
My concern has been that doing "svn merge -r 60" will pull in every
change that has been committed to the entire repository in versions
43-60, *to all files*, and that's almost never what I want.
I don't understand why the Subversion folks are so dead set against
file-based tags. As I said in a post to the user's list at the end
of the last fight over this, it seems like their dominant argument is
that Subversion rulez and CVS droolz, and anything that people want
because CVS has it must be inherently evil. That just doesn't seem
like a productive way to design software to me.
Thanks, Arturo!
janine
On Mar 14, 2006, at 1:08 PM, Arturo Perez wrote:
[EMAIL PROTECTED] wrote:
I was just looking at the branching/merging chapter of the red-
bean book, and it looks like not even having my own working branch
is going to completely save me, because when you go to merge
changes it's still based on a revision, not on a per-file basis.
So I'm still stuck with having work in progress pulled in along
with the work I'm ready to publish, if that work in progress has
been committed.
Well, again. if your changes are to one file for one feature then
there's no problem. The above is only a problem if you want to
merge 1 file from a set of 8 that implemented a change. But I
don't see why you'd want to do that.
Let's say you changed files x.java, x.html, and x.js to add the
latest nifty pulldown calendar function. You committed them and so
they are revision 60. Your production version is in tags/
production and is revision 42.
So you go to the place where you keep tags/production and the
subdirectory containing x.java and you do (I think)
svn merge -r 60 x.java
Similarly for x.html and x.js. Is there _any_ situation where
you'd only want to merge 1 of those three files despite the fact
that all three of them are required to implement the feature? I
don't see why.
I do understand your concern that if you go to your production copy
and you do a svn merge -r 60 you'll get all the changes between 42
and 60. I agree that you don't want that, generally speaking. But
does the above do what you want?
I do like (not!) how the subversion documentation totally ignores/
downplays how important doing a single file merge is. The only
thing I've found after googling for a bit was the one liner at the
end of http://svnbook.red-bean.com/en/1.0/re16.html
-arturo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
