Rebranding moving code around.

[Jeremy Allison]

On Thu, Apr 22, 2010 at 07:03:30AM +0200, Kai Blin wrote:
> 
> I'm not sure that's reasonable, as this suddenly turns me into the single 
> point of failure, and I am quite busy with my dayjob at the moment.

And don't forget Summer of code :-).

> To be completely honest, I don't think it makes much of a difference. I'm 
> knee-deep into the S3 interdependencies right now, and I don't think they 
> will suddenly turn into more of a mess just because winbindd/winbindd_foo.c 
> turns into ../authserver/winbindd_foo.c
> 
> Unless you're talking about the containment of the S3 dependencies in 
> source3/, there's really not much of a difference. It's probably not much 
> work to fix up the waf build for this either.
> 
> There's also code in the top level dirs that isn't shared already, so we do 
> have a prior examples. I really don't see an issue with this.

Thanks. It didn't seem a big deal to me, which is why I proposed
it. It doesn't really change anything other than starts us moving
towards the final structure we committed to in the last blog post.

I'm more concerned about the impact on packagers to be honest, but
I was hoping to have that discussion @ SambaXP (volcano permitting :-).

> That actually depends. If you're talking about getting a list of commits to 
> the new directories like "git log authserver", yes, it'll only show the newly 
> created files. If you're talking about figuring out who the heck wrote this 
> line of code ten years ago, like "git blame authserver/winbindd.c", that 
> still works. git does have a pretty decent rename detection, unless you move 
> too many files at once (like we did on the s3 s4 merge).

Everything was moved with "git mv" so that shouldn't be a problem
I think.

Jeremy.