You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Danny De Koster <dd...@fidelity-soft.be> on 2007/11/13 08:48:41 UTC

how to work more efficiently

Hi all,

 

First of all I have my standard source code in a directory which in under Subversion. Let's say /usr/standard_src/source.4gl

Then I have in another directory almost the same source code of a particular program. This is not under Subversion. Let's say /usr/customer_src/source.4gl

In there I needed to do some modifications special for the customer

 

Now I want to work more efficiently and want to heritance the new modification of /usr/standard_src/source.4gl into /usr/customer_src/source.4gl and keep as much as possible my changes of my customer.

 

How do I proceed??? I studied the manual of Subversion about branches...but I don't really understand how to proceed.

 

Thanks,

Danny

 

 

Met vriendelijke groeten / Sincères salutations / Kind regards,

 

Danny De Koster <ma...@fidelity-soft.be> 

 

<http://www.fidelity-soft.be>   <http://www.fidelity-soft.be/>  <http://www.fidelity-soft.be>   <http://www.fidelity-soft.be> 

 

 


Re: Re: how to work more efficiently

Posted by km...@rockwellcollins.com.
"B Smith-Mannschott" <bs...@gmail.com> wrote on 11/13/2007 12:00:30 
PM:
> On Nov 13, 2007 5:17 PM, Danny De Koster <dd...@fidelity-soft.be> wrote:
> > Hi Ulrich,
> >
> > Thanks for your comment.
> >
> > I've tried to follow the manual and I succeeded, but.... I have a 
> lot of source files in my project and only 1 or 2 source files have 
> some modification for a customer. Do I need to copy the whole 
> project to a branches which can be used for that customer?
> >
> 
> Yes.
> 
> This may sound bad, but it isn't. Subversion needs hardly any
> additional space in the repository for such a copy.
> 
> [quote http://svnbook.red-bean.com/en/1.1/ch04s02.html ]
> [snip...]

While the initial copy requires little space, you are forced to
repeatedly merge in changes to all the customer branches on any
changes of the "common" code.  This is a lot of extra work and is 
essentially
storing the delta for each merge, unless you do a delete/recopy to
all the branches instead.

If possible, I would suggest reorganizing your project to keep the 
"common" code
in one common shared location, and then the customer specific code in 
another.

Kevin R.

Re: Re: how to work more efficiently

Posted by B Smith-Mannschott <bs...@gmail.com>.
On Nov 13, 2007 5:17 PM, Danny De Koster <dd...@fidelity-soft.be> wrote:
> Hi Ulrich,
>
> Thanks for your comment.
>
> I've tried to follow the manual and I succeeded, but.... I have a lot of source files in my project and only 1 or 2 source files have some modification for a customer. Do I need to copy the whole project to a branches which can be used for that customer?
>

Yes.

This may sound bad, but it isn't. Subversion needs hardly any
additional space in the repository for such a copy.

[quote http://svnbook.red-bean.com/en/1.1/ch04s02.html ]

Subversion's repository has a special design. When you copy a
directory, you don't need to worry about the repository growing
huge—Subversion doesn't actually duplicate any data. Instead, it
creates a new directory entry that points to an existing tree. If
you're a Unix user, this is the same concept as a hard-link. From
there, the copy is said to be "lazy". That is, if you commit a change
to one file within the copied directory, then only that file
changes—the rest of the files continue to exist as links to the
original files in the original directory.

This is why you'll often hear Subversion users talk about "cheap
copies". It doesn't matter how large the directory is—it takes a very
tiny, constant amount of time to make a copy of it. In fact, this
feature is the basis of how commits work in Subversion: each revision
is a "cheap copy" of the previous revision, with a few items lazily
changed within. (To read more about this, visit Subversion's website
and read about the "bubble up" method in Subversion's design
documents.)

Of course, these internal mechanics of copying and sharing data are
hidden from the user, who simply sees copies of trees. The main point
here is that copies are cheap, both in time and space. Make branches
as often as you want.

[/quote]

-- 
// Ben Smith-Mannschott

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


RE: Re: how to work more efficiently

Posted by Danny De Koster <dd...@fidelity-soft.be>.
Hi Ulrich,

Thanks for your comment.

I've tried to follow the manual and I succeeded, but.... I have a lot of source files in my project and only 1 or 2 source files have some modification for a customer. Do I need to copy the whole project to a branches which can be used for that customer?


Met vriendelijke groeten / Sincères salutations / Kind regards,
 

Danny De Koster

 



 

-----Oorspronkelijk bericht-----
Van: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com] 
Verzonden: dinsdag 13 november 2007 10:57
Aan: users@subversion.tigris.org
Onderwerp: Re: how to work more efficiently

On Tuesday 13 November 2007, Danny De Koster wrote:
> First of all I have my standard source code in a directory which in under
> Subversion. Let's say /usr/standard_src/source.4gl
>
> Then I have in another directory almost the same source code of a
> particular program. This is not under Subversion. Let's say
> /usr/customer_src/source.4gl

Just that I understand you correctly: you have some sourcecode in a Subversion 
repository (this is the main branch or 'trunk'). Further, you have some other 
sourcecode that is derived from that sourcecode but _not_ in the repository.

BTW: if /usr/standard_src is a path in your (Unix/Linux) filesystem, I'd say 
this doesn't belong there. If it's a path in your repository the name is 
maybe a bit unlucky because it might cause confusion. At least I was confused 
when I read it.

> In there I needed to do some modifications special for the customer

This would be a branch of the mainline sourcecode.

> Now I want to work more efficiently and want to heritance the new
> modification of /usr/standard_src/source.4gl into
> /usr/customer_src/source.4gl and keep as much as possible my changes of my
> customer.

This is called merging changes between branches.

> How do I proceed??? I studied the manual of Subversion about branches...but
> I don't really understand how to proceed.

First thing that you do is create a branch from your sourcecode so that the 
customer-specific parts are under Subversion, too. Then, you can use SVN's 
merging feature to apply changes from the trunk to the branch or vice versa. 

I would say that this is exactly what described in the book though, so I'm
a bit puzzled where the problems lie. Maybe it is that there is some 
misunderstanding between us concerning what you actually want otherwise you 
might want to be more explicit which parts you don't understand.

HTH

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


Re: how to work more efficiently

Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Tuesday 13 November 2007, Danny De Koster wrote:
> First of all I have my standard source code in a directory which in under
> Subversion. Let's say /usr/standard_src/source.4gl
>
> Then I have in another directory almost the same source code of a
> particular program. This is not under Subversion. Let's say
> /usr/customer_src/source.4gl

Just that I understand you correctly: you have some sourcecode in a Subversion 
repository (this is the main branch or 'trunk'). Further, you have some other 
sourcecode that is derived from that sourcecode but _not_ in the repository.

BTW: if /usr/standard_src is a path in your (Unix/Linux) filesystem, I'd say 
this doesn't belong there. If it's a path in your repository the name is 
maybe a bit unlucky because it might cause confusion. At least I was confused 
when I read it.

> In there I needed to do some modifications special for the customer

This would be a branch of the mainline sourcecode.

> Now I want to work more efficiently and want to heritance the new
> modification of /usr/standard_src/source.4gl into
> /usr/customer_src/source.4gl and keep as much as possible my changes of my
> customer.

This is called merging changes between branches.

> How do I proceed??? I studied the manual of Subversion about branches...but
> I don't really understand how to proceed.

First thing that you do is create a branch from your sourcecode so that the 
customer-specific parts are under Subversion, too. Then, you can use SVN's 
merging feature to apply changes from the trunk to the branch or vice versa. 

I would say that this is exactly what described in the book though, so I'm
a bit puzzled where the problems lie. Maybe it is that there is some 
misunderstanding between us concerning what you actually want otherwise you 
might want to be more explicit which parts you don't understand.

HTH

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org