On Jun 12, 2006, at 17:20, Graham Vickrage wrote:
> We are a software development company that has a core system which
> we branch into its own project once we get a new customer.
>
> Development of the project continues however once in a while a
> change to a core module is made which then has to be rolled out
> into the individual projects.
>
> 1. I have tried to branch this core file into the project but as it
> already exists it does not allow it.
> 2. SVN copy - from core to project but this produces same error it
> already exists.
> 3. Merge - this sometimes seem to work however other times the
> content doesn't seem to be changed.
>
> Is the only option to delete the file in the project directory then
> commit the project. Once this is delete try one of the above, in
> which case what should I be using?
You should be using the third option you mention above: you should
merge the change from the core directory to the project-specific
directory. Merging is described in the book, but it can be tricky to
understand. If you're getting errors, or if the changes you expected
are not appearing, it's possible you're telling Subversion to merge
the wrong things. Show us exactly what commands you executed and
their output, and what unexpected behavior you experienced, and we
might be able to help you fix your merge command.
> Also are there any plans to bring in file level versioning into sub
> version? I did see some emails about auto-versioning, is this the
> same thing?
If by "file level versioning" you mean that each file has its own
revision number, as in CVS, then no, I don't think that's going to
happen in Subversion. Why would you want it?
Auto-versioning is unrelated; it means that you can access a
Subversion repository served over Apache as a WebDAV share, which you
can mount as a volume on your computer's desktop, and double-click
and edit the files on it just like on any other mounted volume, which
causes an automatic commit to occur when you save a file. Of course
the commit message is empty, and it's easy in this way to overwrite
others' changes that you haven't seen yet. So it's not great for code
developers such as yourself. It is great for allowing non-technical
people to nevertheless version-control their binary documents somewhat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 12 18:17:43 2006