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

Re: external file

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Sat, 4 Dec 2010 11:01:46 +1000

 On Sat, Dec 4, 2010 at 10:35 AM, Scott Yan <scottyan_at_live.com> wrote:

> Hi, djcbecroft:
>
> Thanks very much for your reply , but I'm afraid that branches can't meet
> my request. Because when we make some change to any projects, we want the
> changes reflect to all other projects just as external does, but when I
> modify a file in a branch, other branches won't know that until I do a
> merge, so , that means if I modify a file in project1, I must goto project2
> to do a merge, and then project3, and then more, besides, we modify the
> files really frequently.
>

Please remember to Reply All to ensure the conversation stays on the list.

Maybe. You can use branches, and then use intra-repository file externals to
avoid merging the changes across.

Cheers,
Daniel B.

----
> Best Regards
> Scott.Yan
>
>
>
> > CC: users_at_subversion.apache.org
> > From: djcbecroft_at_gmail.com
> > Subject: Re: external file
> > Date: Thu, 2 Dec 2010 23:09:57 +1000
> > To: scottyan_at_live.com
>
> >
> > On 02/12/2010, at 20:30, Scott Yan <scottyan_at_live.com> wrote:
> >
> > > Hi,
> > >
> > > At first, thanks for your great works, but our company really need
> inter-repository file-externals feature which is not supported now, so , is
> there any plan to do this?
> > >
> > > Below is our situation:
> > > There are a dozen sub-factories in our company , and we develop our ERP
> system ourselves, because there are very much diffrences between factories,
> our project became a dozen versions, which means we have a dozen repositoies
> for all the projects.
> >
> > This scenario sound like you should probably have one repository with
> separate branches per version, rather than individual repositories. Then you
> wouldn't need externals at all.
> >
> > > Obviously, there are many files are equal in these projects, we must
> share them between projects, but it's very difficult to share the whole
> directory because of many reason such as:
> > > 1. We use VSS before, and VSS support file share between projects, so
> we didn't place share files in seperate folder.
> > > 2. Usually, when we add a new module to the system , the whole module
> is shared in all the projects, but factories will ask some special functions
> for their own request, and there will be more and more files are diffrent
> from other projects.
> > > 3. there are several files are placed at root directory.
> > >
> > > For clearer description, I'll demonstrate our situation:
> > > Suppose there are 3 projects
> > > Project1
> > > Project2
> > > Project3
> > >
> > > There is a "HRManagement" folder in all of them.
> > > There are 100 files in HRManagement folder, 30 of them are equal
> between Project1, Project2 and Project3, but the others are not equal.
> > >
> > > If we make a new folder names "Share" below HRManagement, and place the
> 30 files to it:
> > > HRManagement/Share/sharefile1
> > > HRManagement/Share/sharefile2
> > > HRManagement/Share/sharefile3
> > > ......
> > >
> > > Because we reference sharefile1 as "HRManagement/sharefile1" before, so
> we must search the whole project ( in face, in all the projects, Project1,
> Project2, and Project3) for the old reference , and then change to
> "HRManagement/Share/sharefile1".
> > > And, this is just for a single file! There are sharefile2,
> sharefile3,...... to do the same work, which is impossile at all.
> >
> > And if one of these shared files needed to be changed for a single
> version, you would have to undo all that work. Again, branches sound like a
> better fit.
> >
> > > Thanks for reading this , and I really hope you will add the feature
> ...
> > >
> > >
> > > Best Regards
> > > Scott.Yan
> > >
> > >
>
Received on 2010-12-04 02:02:48 CET

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.