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

Re: Hello, and a branch/merge question

From: <sussman_at_collab.net>
Date: 2004-01-13 04:39:30 CET

> Project/trunk
> Project/trunk/sub (from sub/trunk)
> sub/trunk
>
> -- (I need sub as subdirectory of Project) ---
>
> And now, I will use only Project/trunk/* ...
> so... if later I will merge changes from
> Project/trunk/sub to sub/trunk i will lost
> the data from which dir this was merged.

Why would you lose data? If you commit a bunch of changes to
Project/trunk/sub/, you can always "merge" them back into the original
sub/trunk if you want to. Just compare two different versions of
Project/trunk/sub with each other, and merge the differences into a working
copy of sub/trunk. That's exactly what the 'svn merge' command is for.

> But can I just overwrite (this is enough for me)
> that files ? (by server side copy Project/trunk/sub ->
> sub/trunk) ?

No, 'svn cp' will never overwrite files or directories. I suppose you could
repeatedly delete sub/trunk and then 'svn cp Project/trunk/sub sub/trunk'.

It sounds like you want the *exact* same history to exist in both sub/trunk
and in Project/trunk/sub. I'm not sure why that's important to you. As the
book demonstrates, it's fine if sub/trunk gets a whole bunch of changes
"ported" in a singel commit, all at once. As long as your log message
documents this fact, you can always go back and look at the specific
changesets in Project/trunk/sub whenever you wish. There's no reason for
every changeset to exist as an individual commit on both branches; what
matters is that each changeset exists on *some* branch, and that you can
always find it when you need it.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 13 04:40:31 2004

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.