My situation: I am developing my own branch of an open-source project. I do
not have commit access to the main project's repository, so I cannot work
with a branch in the traditional way. I was surprised to find I could not
find what the common solution to this problem was by googling, perhaps i am
searching for the wrong terms. `unofficial branch` was the best i could come
up with.
Not only am I maintaining my own local branch, but I of course want to track
my own source using my own svn server. So:
http://svn.example.com/project/trunk
and
http://svn.johnserver.com/johnbranch/trunk
What I have been doing is what I have cleverly named a "foreign merge".
Whenever example.com <http://example.com> releases a new changeset, I run
this command from within my local working copy of johnbranch/trunk/:
svn merge -r<previous>:<current> http://example.com/project/trunk
This produces a pleasant and familiar string of U, C, G, etc messages, and
definitely has the desired effect on my actual code files. hooray. BUT:
[1] is there a better, Best Practices way for me to manage my "rogue
branch"? If not...
[2] as an experiment i tried this on an export (not checkout) of my code,
and it didn't work. svn complained that . was not a working copy. This made
me suspicious since, of course, the local .svn information had nothing to do
with the foreign diff information that was coming down the pipe (right?).
Investigating further, i did a diff -rq on a foreign-merged checkout
compared to a virgin checkout, grepping for .svn, and sure enough, my merges
from the foreign trunk project with my local working copy were changing my
.svn/entries files. I don't know a thing about svn file formats and the diff
information was completely meaningless to me. so my question is: are my
merges corrupting my .svn data, locally or on the server?
Thanks
John
Received on Fri Oct 21 05:52:48 2005