File under versioncontrol with individual changes per developer

[Daniel Albuschat <da...@viming.de>]

Hello,

   I have a small problem with svn. There's a file
in the repository that needs to be changed by every
developer in order for the IDE to work properly.
Every dev needs to change a database path variable
in this file, so he has access to the db from within
the IDE, what's very helpful. The variable will get
changed if the program starts anyways, so the info
is only valuable to the IDE.
Well, this file needs to be under version control,
though, since there are other parts that'll change.
But everytime any developer does a commit, he overwrites
the file in the repos with his `new' version, where only
this variable changed. This leads to a huge version list
for this file of course, which is not needed.
And, if a dev updates, he overwrites his database path. So he
has to change it again after each update. This, too, is
pretty annoying.

Is there a way to `ignore' this file when doing a svn commit,
but make it possible to explicitly commit it via 
svn commit <file>?
This would be really helpful.

Or perhaps you have other ideas how we could circumvent this.

Regards,
   Daniel Albuschat

--
eat(this); // delicious suicide

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

Re: File under versioncontrol with individual changes per developer

[Gregor Fabritius <gr...@gmx.de>]

Daniel Albuschat wrote:

> In my case, the file is *not* generated in *any way*. As I said, it's
> simply sourcecode. And you have to change only the path to the database.

I had a similar problem using Delphi7 Project Groups. I solved it using 
relative paths such as ..\..\bin etc.

HTH, Gregor

Re: File under versioncontrol with individual changes per developer

[Daniel Albuschat <da...@viming.de>]

Ben Collins-Sussman wrote:
> [pretty please, stop mailing me personally, and keep the discussion on
> the list!  :-)  ]

Eeek, sorry! Didn't even notice it. Dunno why thunderbird replied to you
instead of the list... and I didn't manually check the "To:" field.
Shouldn't the `Reply-To' be set to users@subversion.tigris.org?

> On Sun, 2004-07-18 at 09:15, Daniel Albuschat wrote:
>>This is a totally different story. In this case, configure.in can be
>>`compiled' to configure. So, of course, you shouldn't put it under
>>version control, since it's redundant and sometimes inconsistent and
>>error-prone (if the configure doesn't match the configure.in, for
>>example).
> 
> I don't think it's a different story at all.  People write build scripts
> that run 'autoconf' on configure.in, which produces configure.

And we don't run any script to create our developer-dependent file.

 > Everyone
> who checks out a working copy understands that the build system must
> "convert" the template to an customized, unversioned file.

This is not a template in this sense. It's more a kind of `sourcecode'.

 > It doesn't
> matter whether the "conversion" involves running a fancy program like
> autoconf, or if it's just a matter of running 'cp'. 

There's a big difference. The resulting file follows totally different
syntax rules.

> The point is that
> the customized file is auto-generated in one way or another, so it's the
> template that's put under version control, not the generated file.

In my case, the file is *not* generated in *any way*. As I said, it's
simply sourcecode. And you have to change only the path to the database.

> Unlike SCM tools like clearcase (which come with their own 'make'
> tools), Subversion is not a build system.  Our philosophy is to avoid
> adding features that a build system should take care of.

Yep, that's what I think, too. I didn't mention any build system
functionality at all, though.

cu,
    Daniel Albuschat

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

Re: File under versioncontrol with individual changes per developer

[Ben Collins-Sussman <su...@collab.net>]

[pretty please, stop mailing me personally, and keep the discussion on
the list!  :-)  ]

On Sun, 2004-07-18 at 09:15, Daniel Albuschat wrote:
> Ben Collins-Sussman wrote:
> > Using templates as part of the build system is the most common thing in
> > the world.  Heck, check out a copy of subversion itself and notice that
> > even 'configure.in' is under version control, but 'configure' is not. 
> > Count how many "*.in" files are versioned and are converted to
> > unversioned files by the build system.
> 
> This is a totally different story. In this case, configure.in can be
> `compiled' to configure. So, of course, you shouldn't put it under
> version control, since it's redundant and sometimes inconsistent and
> error-prone (if the configure doesn't match the configure.in, for
> example).

I don't think it's a different story at all.  People write build scripts
that run 'autoconf' on configure.in, which produces configure.  Everyone
who checks out a working copy understands that the build system must
"convert" the template to an customized, unversioned file.  It doesn't
matter whether the "conversion" involves running a fancy program like
autoconf, or if it's just a matter of running 'cp'.  The point is that
the customized file is auto-generated in one way or another, so it's the
template that's put under version control, not the generated file.

> 
> > So no, I don't think there's any planned feature to teach 'svn commit'
> > to ignore versioned files.
> 
> Well, I was thinking about putting this template-trick into
> the subversion command, somehow. Something like this:
> "svn template <file>"
> will copy <file> to <file>.tmpl, putting <file>.tmpl under version
> control and put some info into the repos, that when doing a checkout,
> svn should copy <file>.tmpl to <file>.
> This way, you can compile right ahead, without knowing about template
> files and/or looking for them.
> And, if <file>.tmpl changes, svn can give a message like: "Compare your
> <file> to the <file>.tmpl file, because the template changed and you
> have to make changes to your local copy accordingly.".

Unlike SCM tools like clearcase (which come with their own 'make'
tools), Subversion is not a build system.  Our philosophy is to avoid
adding features that a build system should take care of.

(I am not the Subversion project, but this has come up on dev@
discussions before, and I think this is the general consensus.)

> 
> But this is just a thought. I know that subversion doesn't put it's
> `philosophy' into the command structure (like with branches, tagging,
> etc.). But then again, this template-trick should be described in the
> documentation (and/or the subversion book), too.

Hm, yeah, I guess almost all of the FAQ's should go into the book at
some point.  :-)




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

Re: File under versioncontrol with individual changes per developer

[Ben Collins-Sussman <su...@collab.net>]

On Sun, 2004-07-18 at 08:40, Daniel Albuschat wrote:
> Ben Collins-Sussman wrote:
> > On Fri, 2004-07-16 at 08:51, François Beausoleil wrote:
> > 
> >>I can only offer a workaround...
> > 
> > This is a common FAQ, so I just added it to our FAQ:
> > 
> >   http://subversion.tigris.org/project_faq.html#ignore-commit
> 
> Thanks for the answers. I guess this will work.
> 
> Perhaps there might be a `built-in' solution in an upcoming
> subversion release, though? There actually *are* ways how to
> handle this properly I guess.

Using templates as part of the build system is the most common thing in
the world.  Heck, check out a copy of subversion itself and notice that
even 'configure.in' is under version control, but 'configure' is not. 
Count how many "*.in" files are versioned and are converted to
unversioned files by the build system.

So no, I don't think there's any planned feature to teach 'svn commit'
to ignore versioned files.



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

Re: File under versioncontrol with individual changes per developer

[Ben Collins-Sussman <su...@collab.net>]

On Fri, 2004-07-16 at 08:51, François Beausoleil wrote:
> Daniel Albuschat wrote:
> > Or perhaps you have other ideas how we could circumvent this.
> 
> I can only offer a workaround...

This is a common FAQ, so I just added it to our FAQ:

  http://subversion.tigris.org/project_faq.html#ignore-commit




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

Re: File under versioncontrol with individual changes per developer

[François Beausoleil <fb...@ftml.net>]

Daniel Albuschat wrote:
> Or perhaps you have other ideas how we could circumvent this.

I can only offer a workaround...

What I usually do with files like this is to have a *.sample.  This file 
*is* under VC.  I also set svn:ignore to the * part.

A specific example:
build.properties.sample -- Contains the base values, with dummy passwords
build.properties        -- A copy of sample, with actual values in it

This I use with Java and Ant.  It works pretty well.

What I would propose is to have another file with the developer specific 
line in it, only.  That file would not be under VC.  Put a sample file. 
  Then, during your build, (or after updating), concatenate both files 
together to the target filename.

For example:
build.properties.sample  -- VC'd file
build.properties.dev     -- developer-specific file
build.properties         -- Automatically generated file

So, checkout and update would become
svn update && cat build.properties.sample build.properties.dev >> 
build.properties

Hope that helps !
François




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