On 7/27/07, Julien Nigay <killergege@gmail.com> wrote:
> > The standard advice is: http://subversion.tigris.org/faq.html#ignore-commit
> >
> > What I have done with my applications is to split the configuration
> > files up. "Global" settings go in one config file named
> > global.properties. Settings which are specific to a particular OS go
> > in a config file named OPERATINGSYSTEM.properties (where
> > OPERATINGSYSTEM is Linux, Windows XP, Windows 2003, etc.). Settings
> > which are specific to a particular computer go in a config file named
> > COMPUTERNAME.properties. At build- or run-time (depending on what
> > you're doing), the build system or the application itself determines
> > which config files it needs to load.
> >
> > By doing this, the primary developer, who works on Linux, our servers
> > (some of which run Win2K, some Win2K3) and I (running WinXP) all have
> > our configurations set appropriately, without having to screw around
> > with changing configurations which would mess another environment up.
>
> OK...
>
> Let's see another problem we faced, maybe a better example :
> - it's a company development : only one OS target, consistent IDE and
> dev plateform, no real release management so all the devs are on one
> branch, with tags for releases.
> - there are 2 parts in our application : a web application and a
> webservice. The webservice uses the application DAO.
> - I'm working on the application / DAO, someone else on the webservice.
> - the DAO is not set at the beginning as the database structure is not
> yet defined.
> - the webservice developer has started to develop in order to do some
> tests. He created "test" DAO objects.
> - We are under heavy development, the repository is never consistent
> and only used to share code and backup files.
> - When the database is defined. I remove the test DAOs and create the
> right objects.
> - the webservice developer is on a specific development and don't have
> the time to adapt his code to the new DAO objects.
> - the project doesn't compile because of webservice classes.
> - I comment the webservice code and only keep the method declarations.
>
> The problem is the same : I did temporary editing on my computer in
> order to make MY code compile because I don't care testing HIS. But I
> don't want to commit that. When the webservice developer will change
> his code, he should not have to resolve a conflict (even if it's
> simple : just replace the server's data) and if I face a conflict,
> that's alright because I'm expecting it.
Or perhaps you could change your build process so that such editing
isn't required in the first place - instead, specify options in
calling your build process to skip compiling the other guy's code
(when you don't want to).
It sounds like your repository structure, working copy layout, or
maybe even your project structure isn't set up to facilitate
independent work on loosely-coupled "subprojects." Maybe that should
be fixed, instead of trying to make the source control tool bend to
fit a suboptimal setup.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Jul 27 18:03:01 2007