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

Re: how to add $Id$ automatically

From: p karthik <karthik1212_at_gmail.com>
Date: 2007-11-21 18:16:06 CET

Hi All,

Thanks a lot for your quick responses.
I have ended up with a pre-commit hook script which would fail the commit if
the file doesn't have the $Id$ in it.
I think it's a better and much more controlled way of doing.

Thanks a ton guys!

Cheers,
Karthik.

On 11/21/07, Scott Gifford <sgifford@suspectclass.com> wrote:
>
> "p karthik" <karthik1212@gmail.com> writes:
>
> > Hi Sohail,
> >
> > Even I don't think adding $Id$ would break the application in any way. I
> know
> > that we are just adding the version information to the file.
> > But the thing is, as we are now in a end to end testing phase, which
> involves a
> > lot of resources, we would be needing patches for all the defect fixes
> which
> > arise during the testing.
> >
> > As we are against the "cherry-picking" concept, which means we don't
> take only
> > some files from Subversion to build a patch, implies we need to take
> each and
> > every file for the deployment if it has changed for any reason. If we
> modify
> > the files by adding $Id$ in to the file those require a commit and
> consequently
> > they would be going as a patch which would have huge number of files,
> and which
> > is not intended as a deployment downtime per se.
> >
> > So the only way I have is to add this $Id$ with out actually commiting,
> but the
> > files should be having $Id$ in Subversion.
>
> Hi Karthik,
>
> That really sounds like a problem with your process. The post-commit
> hook you are looking for will have the exact same end result as
> checking everything out, modifying the appropriate files, then
> committing the results. The only difference is that it will take
> longer, and be easier to make a mistake that could cause damage to
> your SVN archive, or corrupt the files in unexpected ways.
>
> If your processes require you to do things in a more difficult and
> error prone way to achieve the same results with the same or worse
> risk of breakage, you should take a look at fixing them.
>
> I know that's not what you wanted to hear, but hopefully it's helpful
> anyways. Good luck,
>
> ---Scott.
>
Received on Wed Nov 21 18:16:43 2007

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.