[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

unique branch problem

From: John Joseph Bachir <johnjosephbachir_at_gmail.com>
Date: 2005-10-21 05:50:32 CEST

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:




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?

Received on Fri Oct 21 05:52:48 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.